DDD modeling explained by example
Adopting DDD introduces a lot of terms and often looks daunting. There are many design techniques and an entirely new vocabulary. High-level design flows seamlessly into technical implementation techniques causing people to lose track.
In this beginner-level post, I will demonstrate well-known modeling techniques from high-level to implementation of services design.
High-level DDD models and your organization
This post exemplifies how DDD helps to create abstractions from real-life business and organizational structures to system designs. DDD modeling techniques capture the best semantics and create a design structure that provides for a healthy foundation of a modern platform. DDD unifies business and IT using a common language and an aligned structure.
Although the post reads like a linear process, reality often isn’t. The primary benefit from any DDD-influenced effort in my view is to align both the design space and the implementation space to the business domain you are supporting by creating a common language, in reality in cycles.
The place where DDD creates the most benefits is where you want the software to support a business process that encompasses multiple disciplines, departments, roles, and even cubicles ;). Which is the majority of business-supporting IT.
Step 1. The organization structure
Our example presents us with an insurance company for which we will model software for Product A. The actual company organization structure will give you the right diversity of stakeholders and a basic lay of the land. You will invite these stakeholders for the next step.
Step 2. Use Eventstorming for modeling your processes
Eventstorming will map out the detailed business process implementation of Product A. This collaborative modeling technique aims to capture the business process. Experience shows it’s a great way to get business complexity on the table and into the heads of engineers.
In the image below we read left to right, you see stickies in blue referring to triggers or actions, followed up by yellow stickies flagging events on something that happened. We fork to parallel sequences of stickies when things happen in parallel (or for alternative and optional flows).
While older modeling techniques like BPMN and UML also had their set of techniques to describe the problem space, Eventstorming keeps the first discussions to a simpler recognizable (by business) level. Often it feels like the result of an Eventstorming could be 'owned and embraced' by the business. That's a win that you should embrace when you have the desire to improve business IT integrations.
Step 3. The high-level domains
With careful analysis of the two steps before it’s possible to identify domains. We look for places in our process map that could serve as a point of separation where we can confine our understanding of that sub-process to a subdomain. Often you see it visually emerging in forks and joins of sequences of stickies. Sometimes influenced by the organizational structure. Or because of inherent stages of the process that flows linearly with time like the one below.
Step 4. The Context map
The context map will model - for each domain - the important concepts to us and how they relate.
This level of modeling feels more engineering than business. It's regularly mistaken as some kind of database model.
It’s important to note we identify similar concepts in different domains in the diagram below. The domains provide isolation of the concepts to the domains’ bounded context. It means the same concept will mean something different in different domains.
Moving to implementation
In DDD, design and implementation fuel each other and develop a common language. Domains consist of a bounded context in which their core data have their own independent meaning. De data flow in that bounded context is regularly modeled in DDD with commands (intents or actions to change the system’s state, and events (captured explicit state changes).
Our business rules are the core value of our systems. In DDD we use aggregates to process commands and turn them into events. This is where the majority of our business rules are executed.
Implementation level designs for DDD
In classic DDD there is no official design method for the aggregate layer. The best place to capture business rules is always code. However, code is impossible to share with business stakeholders. So I like to visually model commands and events flow as well. In practice, you can find multiple ways to diagram the implementation, from boxes-and-arrow diagrams, C4 diagrams, to more strict Archimate and TOGAF diagrams.
Step 5. Aggregate design
The Aggregate design model below models the flow of commands and events and help to model complex transactions.
Step 6. Service mapping
The service mapping bundles aggregates into logical platform building blocks that can be built and deployed. Services are recognizable in our IT landscape and often referred to inside and outside IT.
Validation and design cycles
We started out with our organizational design. Afterward, we modeled our business processes for Product A, the domain, our bounded contexts, and aggregates. In DDD the business process is a first-class citizen. In real life, we would go over and over our designs and re-iterate until we get to great semantics and have captured the process with great accuracy.
Wrapping up
Hope you enjoyed this post and you are starting to see how DDD designs on different levels relate to each other. If you have questions, let me know in the comments.
I also put this post into a nice A4 poster. It is easy to refer your fellow DDD enthusiast. The DDD poster is shared on my LinkedIn.
Some additional resources that you mind be interested in:
