Domain Driven Design - a summary of 50 years experience and wisdom of the software developer community
Our Chief Technology Officer at #icontest, Gustin Ágoston Gábor gave the last #knowledgesharing presentation at our regular #teammeeting. The topic in which Gustin has many years of experience and has written about on his blog (https://gustinsblog.wordpress.com/2015/10/28/domain-driven-design-executive-summary/) is Domain Driven Design, aka #DDD. During the presentation, we got to know DDD on a #strategic and a #tactical level. Gustin used a running project of ours to illustrate the theory with practical examples.
Domain Driven Design is an approach to #softwaredevelopment that emphasizes understanding and modeling the core business domain of a system. The goal of DDD is to help create software systems that reflect complex business domains, by establishing a common language between all project participants (developers, domain experts...etc.) and by using this language to build a shared understanding of the #businessdomain.
Gustin presented the high-level characteristics of this software development method, so we could take a helicopter view of DDD’s tools, practices, and benefits. On top of that, we got to know some tactical elements too. In the beginning, we played a so-called “Context game” where we could experience how different contexts indicate different use of language.
In the beginning, Gustin said that DDD is the current state of a 50-year-old evolutionary process of the software community about how to tackle (very) complex problem domains. Eric Evans in his book (2003) made the resynthesizing and restructuring of gathered experience and appeared concepts and best practices of the past decades - declaring the new term DDD. It’s surely not the end station – instead, most likely going to evolve further in the next decades as well.
As Gustin writes on his blog: “Generally, the overhead of DDD itself costs more than most of its alternatives for tackling different (usually simpler) problem domains. Therefore, the problem domain your software project addresses must be complex enough to be worth the overhead DDD brings in. So, the general rule is: if you have a simpler problem that can be generously handled with simpler alternatives then say no to DDD and let apply a simpler approach instead. On the other hand, if you have a complex problem domain, many of the alternatives will show their limits – in maintainability as well as in complexity. I.e. your project will likely get into very high maintainability costs – whereas, at the same time, it will reach a complexity limit you just cannot raise further. Now, that’s a clear #context for DDD – to avoid all this.”
In tactical DDD, the focus is on identifying the most important concepts and entities within the #businessdomain and modeling them using diverse (object-oriented, functional, reactive…etc.) programming techniques. DDD also emphasizes the importance of defining boundaries and relationships between different parts of the system, and encapsulating domain logic within domain objects and aggregates.
DDD provides a set of tools and practices for building software systems that are both flexible and robust, and that can evolve as the business domain changes. This includes techniques for mapping domain concepts to code, managing domain complexity, and testing and validating domain models.
The two basic concepts on which the whole DDD approach stands or falls are creating a "domain language", the so-called #UbiquitousLanguage, and defining #BoundedContexts. It is crucial that we can find a domain language that can be used for naming the fields in the database tables as well as conversations with key users and domain experts. We have to create it during the project and then continuously maintain it. The Latin term (Ubiquitous) also indicates that this language must be valid everywhere and carry the same meaning within the limits of a given “Bounded Context”. The goal of Ubiquitous Language is to establish a shared understanding of the business domain and to use this shared language to develop software systems that reflect the complex business domains they serve.
Another key step is to clearly define the Bounded Contexts within which we can use a Ubiquitous Language. Domain languages are related to each other, yet they are clearly and easily distinguishable. E.g. a name may appear in two different contexts, so in two different domain languages, but here their properties, which are important from the point of view of the given context, are different.
In Domain Driven Design, a Bounded Context is a linguistic and logical boundary around a specific area of the business domain. It is a key concept that helps to manage complexity and create clear boundaries between different parts of a software system.
In practice, a #BoundedContext can be defined based on factors such as the scope of a particular business process or transaction, the organizational structure of a business, or the technical constraints of a software system. By defining clear boundaries between different Bounded Contexts, development teams can better manage complexity and reduce the risk of misunderstandings and conflicts between different parts of a system.
A good question is how to create different Bounded Contexts. This can be done with the help of interviews with users, workshops, and a kind of natural, intuitive feeling. It is worth devoting sufficient attention and energy to this phase because it causes a lot of work if we define the boundaries of the bounded context incorrectly. Merging two Bounded Contexts causes a bigger issue than separating them.
Ubiquitous Language involves identifying the key concepts and terms within the business domain and using those terms consistently throughout the development process. This means that developers and domain experts should use the same terms to refer to the same concepts and that these terms should be used consistently in code, documentation, and conversations.
By establishing a Ubiquitous Language, development teams can create software systems that are more closely aligned with the needs of the business, and that is more easily understood and maintained by all members of the team. This can help to reduce the risk of misunderstandings and miscommunications and can lead to more effective and efficient development processes.
It is important to always determine which is the #CoreDomain, i.e. the set of processes that play a prominent role in our project and are the most critical, these are the reason why we build the software at all. It is worth demarcating this domain so that it remains as simple and transparent as possible, since its development has the highest priority, we put the most effort into this, and employ our best developers. In addition, the other domains we can categorize as #GenericSubdomain, which we do not need to develop, we can buy software off-the-shelf for it. Or as a #SupportingSubdomain, which is sufficiently organization-specific to make modifications to purchased software.
The use of #Microservices for the development process works very well together with DDD, and they have roughly a common development path. It can be stated that in most cases a microservice corresponds to a bounded context, but there are exceptions.
The connection between DDD and Microservices is that DDD can help to identify the boundaries and responsibilities of each microservice, by defining Bounded Contexts and by identifying the key domain concepts and entities that each microservice should be responsible for. By using DDD to create a shared understanding of the business domain, development teams can better design and implement microservices that are well-aligned with the business needs and that can evolve as the business domain changes.
By using DDD in conjunction with Microservices, development teams can create more scalable, maintainable, and effective software systems that reflect the complex business domains they serve.
It can be a warning sign if we have over-segmented the processes, then we have created too many microservices, in which case there are too many synchronizing operations, so there are more technical operations in the system than business ones. In such cases, we should review and reduce the number of microservices.
The tactical level of DDD involves the "how" of implementing DDD principles in the code and design of a software system, and it provides developers with specific guidelines and techniques for building software that accurately reflects the complex business domains they are meant to serve. Just like blueprints are used by architects and builders to construct a building according to the desired specifications, the tactical level of DDD provides developers with a set of tools and techniques to build software systems that align with the needs of the business domain. These techniques may include things like creating domain models that capture the behavior and relationships of the business domain, using aggregates to encapsulate complex business rules, employing repositories to manage persistence, and employing event-driven architectures to handle domain events.
Overall, DDD is a powerful approach to software development that can help teams build more #effective and #maintainable systems, by focusing on the core business domain and by using a shared language and understanding to drive development. Properly applied, DDD can lead to significant benefits in terms of software quality, alignment with business needs, and scalability, but it does require careful consideration and management of the associated risks.
Sources:
https://gustinsblog.wordpress.com/2015/10/28/domain-driven-design-executive-summary/
https://gustinsblog.wordpress.com/2016/01/27/ddd-elevator-pitch/