Introduction to Domain Driven Design

When developing the large enterprise application, if the application is not properly designed you will face many problems in maintaining and in enhancing the application. Similarly if the domain is complex the application will be more difficult to develop and maintain. So to avoid the future problems, here the DDD comes in to play.

DDD comes with the solution to manage the big and complex domains and also the software complexity. Domain Driven Design (DDD) is basically not the technology or methodology. Basically it’s the set of patterns and principles for focusing on the design efforts where it matters the most that is domain. This idea was brought in to the world by Eric Evans in his book “Domain-Driven Design: Tackling Complexity in the Heart of Software”. In Domain Driven Design, knowledge of Domain is very important. In domain driven design we just focus on the domain and all the business logic related to domain.

“Domain-driven design is not a technology or a methodology. DDD provides a structure of practices and terminology for making design decisions that focus and accelerate software projects dealing with complicated domains.”

“A sphere of knowledge, influence, or activity. The subject area to which the user applies a program is the domain of the software.”

The domain is our trade, or sphere of activity. Some common examples of domain are trading, finance, e commerce, cargo shipping. For example lets say you are going to develop the trading application, the requirement are:

• You have to subscribe to the stock prices.

• Then you will have to run the strategy to trade the stocks.

In this scenario what your domain is? Trading. Yes that might be, but when you see trading word it includes stocks, bonds, commodities and many other things. So you will need to narrow down the domain to “Stock Trading”, as if you consider full trading you will lose the important requirement related to stock trading.

The basic principle of DDD is to just focus on the domain and the domain design is based on the model. The domain model is the heart of the application. When doing domain driven designing we have domain experts on one side and the software developers on the other side. Software developer are expert in developing the applications using the different patterns and the technologies whereas the domain experts know all about the domain and all the business logic of the domain which developers don’t know. So then how will both communicate as the technology terms will be difficult for the domain experts to understand, same with the domain terms will be difficult for the developers to understand. Since effective communication between these two is very important in order to build a large enterprise application covering that specific domain. So DDD has this solution which is called the “Ubiquitous Language”. I will not go in detail about this, as it’s just the introduction to the DDD.

In the next series of articles we will move ahead with all the terminologies, concepts and the design patterns of DDD one by one in detail. We will use the cargo tracking / automated trading domain to cover all the topics of DDD. The knowledge about the trading domain will be provided in the next articles before starting with the DDD patterns in details so that to understand the concepts with a scenario.