Why is DDD important?
You have probably heard about the Domain-Driven Design (DDD) approach first introduced in Eric Evan’s blue book “Domain-Driven Design: Tackling Complexity in the Heart of Software”.
The primary goal of DDD is to understand the users’ problems through a collaboration between the technical teams and the domain experts and build the software that will hopefully solve the domain problems. The DDD approach is particularly useful when working on a complex business domain.
The domain experts are usually not aware of how complex are the business models in their heads because they are working on the same business for some time and they forgot all the inherent complexity of their business. Even if they are aware of this complexity, it is still hard to dig out this knowledge about the domain from their minds.
How can the DDD help you?
The DDD approach uses a collection of patterns and practices to help create business models, and refine and organize them.
One of the important aspects of the DDD approach is to use the language of the domain in your communication, documentation, stories, and most importantly in your code. When you are learning a business domain to model it and code it, you will need to use a language used by the domain experts to express the domain problem you are building an application for.
By using this language to represent a shared understanding between the domain experts and the technical teams and reflecting this language in the design diagrams and more importantly in the code, the result is a more accurate representation of the domain you are building the software for.
This same domain language is used everywhere; it is what Eric Evans calls the Ubiquitous Language.
During the process of understanding the problems, you will create a model (or models) that represent the domain problem(s) using the ubiquitous language. But what is important to keep in mind is that you are not creating a single model that represents all the problems in your domain but you would rather build a model for each set of problems that are related to your domain. And each model will have its own ubiquitous language.
You can look at a model as “a system of abstractions representing selected aspects of a business domain”. You will need to define boundaries between the models that you are building and that address each specific problem as illustrated in the diagram below.
The models don’t have to use UML diagrams. You can use any representation that is useful for you and your domain experts. The intent of the model is not to represent all the details but focus on specific information and abstract other information that is irrelevant.
The bounded context represents the boundary of the ubiquitous languages and the models. It will help enforce ubiquitous language within a bounded context. In other terms, if there is a “conflict“ in Ubiquitous language it may mean that you need to have another Bounded Context. Each bounded context has its own ubiquitous language and its model that address specific business problems such as Invoicing or Inventory bounded contexts as shown in the diagram above.
If you want to learn more about DDD, I highly recommend listening to this video What is DDD – Eric Evans – DDD Europe 2019.