Modern Software Architecture (#1): Domain Driven Design
Modern Software Architecture with Domain Driven Design (DDD). Introduction on DDD and its relation to Microservices, Reactive Systems, BPM, Agile, CQRS and Event Sourcing.
Welcome to the first issue on Modern Software Architecture. Regularly, I collect and curate interesting and insightful news and stories for a specific topic within the field of Modern Software Architecture. I want to share my experience as software and enterprise architect with you. This article is relevant for software developers, engineers and architects who want to up-skill themselves and learn from expert experiences.
Quick Introduction to DDD
Domain driven design (DDD) is now around for ~15 years. The name was coined by Eric Evans in his book “Domain-Driven Design: Tackling Complexity in the Heart of Software”.
Domain-driven design (DDD) is an approach to developing software for complex needs by deeply connecting the implementation to an evolving model of the core business concepts.
Its premise is:
- Place the project’s primary focus on the core domain and domain logic
- Base complex designs on a model
- Initiate a creative collaboration between technical and domain experts to iteratively cut ever closer to the conceptual heart of the problem.(Source: dddcomunity.org)
DDD is not a technology, rather it introduces terms, practices and principles to support decision making in complex business domains. If the complexity of the domain is not addressed early and properly within the application design, the best technology won’t help to create a system which is maintainable, extendable, etc.
Further, DDD introduces an ubiquitous language which can improve collaboration of cross-functional teams. This language helps to bridge the famous “symmetry of ignorance” between people with different backgrounds and viewpoints, e.g., domain experts understand the practice and system designer understand the technology. (Further reading: Symmetry of Ignorance, Social Creativity, and Meta-Design by Gerhard Fischer)
DDD takes some time to grasp, but it is worth the effort. In the following I give you some resources to better understand what DDD is all about, and in which contexts DDD is used today.
Get to know DDD — A shortcut
Many people state that the original book by Evans is cumbersome to read and understand. But most say, that it is a must read for every software developer or architect who want to build modern software systems. If you are searching for a shortcut, then probably this Minibook on DDD is your next read: “Domain Driven Design Quickly”, which you find on the InfoQ page for free download.
Another great resource is the reference guide on DDD which can be found here:
Practical experience on DDD
If you already know the basics, then you may ask: “How do I apply DDD in practice, and which challenges will I face”. Questions like this and some solutions can be found in the recently released Minibook: “Domain-Driven Design in Practice”, which can be found on the InfoQ page for free download.
DDD & Microservices
In the context of Microservice Architectures, developers and architects searched for a method or utility to define the scope and size of each Microservice. Defining this boundary is not easy and if the fundamental decisions on how to “cut” was wrong, the system will rapidly evolve into the famous “big ball of mud”. DDD introduced the concept of bounded contexts which helps answering the questions.
But DDD contains more concepts and principles which help to create robust and maintainable systems. Michael Plöd gave a presentation on how DDD principles can help to create good Microservices.
DDD & Reactive Systems
Modern systems are nowadays more often reactive and distributed using asynchronous messaging. Such architectures directly lead to challenges such as handling of multiple messages or out-of-order deliveries. In a recent article Vaughn Vernon shows how DDD can aid managing this uncertainty through the use of good modeling.
DDD & BPM
DDD is also helpful in the domain of business process modelling (BPM) to avoid BPM Monoliths which Bernd Rücker explains:
DDD & CQRS & Event Sourcing
Event sourcing is an approach to store data using deltas rather than their effects. The associated database is called event store and uses only the SQL statements INSERT and SELECT. Although event sourcing is not part of DDD, both concepts complement each other very well. (Source: Golo Roden on thenativeweb.io)
The design pattern CQRS describes the separation of the write side from the read side of an application. CQRS and DDD do not necessarily belong together, but complement each other excellently, which is why their combination is often used in practice. (Source: Golo Roden on thenativeweb.io)
Although the concepts stand on their own and can be applied separately, it can be observed, that all three together are often combined. An introduction on this topic can be found in the following article series. The series starts with a motivation on “What’s wrong with CRUD”, explains CQRS and Event Sourcing in more details, and ends with “wolkenkit”, which is a CQRS and event sourcing framework for JavaScript and Node.js for applications modeled using domain-driven design.
DDD & Agile
When it comes to modelling, the first reaction is often: “Modeling does not fit into agile, because it is big up front design (BUFD) which is an anti-pattern in agile.”. For modeling in the context of DDD I disagree. Concepts from DDD even support the agile way very well. There are many agile thought leaders who support and push DDD, e.g., Martin Fowler on his webpage or Kent Beck on the back-cover of Evans book on DDD. And if you want to get things right, sometime you need to think about it a bit longer. Don’t just rush into it, especially if you apply sophisticated concepts such as CQRS & Event Sourcing.
Michael Douglass article explains it very well how DDD and Agile relate to each other:
Too many definitions? Read the FAQ!
With DDD a lot of terms and concepts are introduced. Especially, if you dive deeper into DDD with CQRS and Event Sourcing. To understand how all these concept fit together, the following FAQ is a great resource.
Want to read more?
Subscribe to my newsletter on modern software architecture. Grow your skills and become a better software architect.
