by Domain Driven Design or DDD is a software development technique. This article explains about the basic overview of Domain Driven Design (DDD), some key features of DDD. Summary of the article:
- What is Domain-Driven Design (DDD)?
- History of DDD
- How do we do DDD?
What is Domain-Driven Design (DDD)?
Domain Driven Design or Domain Driven Development (DDD) is a software development process or approach which focuses on understanding the customer’s problem domain. It does not contain only the technical ideas, but also contains the techniques to structure the creativity in the development process. It is the idea of learning the vocabulary of a domain and using the vocabulary to communicate.
In order to develop good software, at first we have to know the core business of that system. We can’t develop banking software unless we have a good understanding or clear concept of banking system. That means we must understand the domain of banking.
The key of this approach understands the customer’s needs, and the environment or atmosphere in which the customer works. In DDD, the development is guided by the exploration of the problem domain.
When a developer discuss with customer to understand his needs and wishes, he/she creates a model which reflects the current understanding of the problem. This model is called Domain Model. The model should accurately reflect the problem domain of the customer.
Then, the domain model is tested with some real use-cases to understand if it fits to the customer’s processes and way of working. Then, the model is refined again. The whole process of discussion with the customer starts again. That why, Domain Driven Design is an iterative approach to software development.
History of DDD
The term Domain Driven Design was coined by Eric Evans in his book “Domain-Driven Design”.
How do we do DDD?
The steps are given bellow:
- At first, find a domain expert. Talk with him and learn the vocabulary of the domain
- By using these vocabularies and with the help of domain experts develop a model. The model can be textual, like a use case. Consider that diagrams are more preferable for understanding
- Continue iterating with the domain experts on the model until clear understanding of the problems which need to be solved
- Translate the model into code with DDD practice. If it is needed to implement something different from the model, re-examine the thinking for the model and modify it
The domain driven design is a powerful concept for software development. But it is a big challenge to developed applications really with DDD. The more we practice this concept for designing object model, the more accuracy we will gain. The most important thing is we need to think in domain driven way. Unless may suffer in deep trouble when the application is real complex.
DDD is an essential architectural process in both the microservice and the agile worlds. It’s a great way to come up with an architecture for highly modular systems that can grow incrementally as the system evolves.
It has several characteristics, the first of which is that it is a collaborative process. “Business people and developers “working together,” comes from the agile manifesto.
The second characteristic is that DDD is built on the notion of modelling. The basic idea is that the structure of your code should model or map to the structure of the domain within which the problem is being solved.
The third characteristic of DDD that’s important is that it’s incremental.
The basic idea is that a DDD architecture will allow your code to grow incrementally over time because the architecture itself grows incrementally over time.
Thanks Kamrul Hasan for your valuable opinion.