Domain Driven Design and Event Storming - javaplus/StreamingWorkshop GitHub Wiki
What is Domain-Driven Design?
Domain-Driven Design is a concept introduced by a programmer Eric Evans in 2004 in his book Domain-Driven Design: Tackling Complexity in Heart of Software.
It is an approach for architecting software design by looking at software in top-down approach.
Domain - this refers to the Business directly. DDD approaches software design through the lens of the business problems at hand. It does so through:
Bounded Context - which describes the boundary conditions of the domain, or more simply put, tells us what's in and what's out.
Ubiquitous Language - a common language used by all team members to connect work to the model.
Models - represents the core aspects of the domain and is used to solve related problems.
What is Event Storming?
Event Storming is a flexible workshop format for collaborative exploration of complex business domains invented by Alberto Brandolini in the context of Domain-Driven Design (DDD). The basic idea is to develop a the domain, models, bounded contexts, and ubiquitous language through a fun learning process.
The following steps and images are adapted from Judith Birmoser's Event Storming Template, a template you can use in the online collaborative whiteboarding service Miro.
Event Storming Components
Event storming is a collaborative process that involves everyone who is participating in creating a solution from both business and IT, as well as a facilitator. The result is a set of domain models, as we’ll see in the next few minutes. The process uses 7 basic building blocks, all centered around domain events.
Domain Event - An event that occurs in the business process. Written in past tense. For example, “Customer Opted-Out” or “Customer Moved”
View / Read Model - A view that users interact with to carry out a task in the system.
User - A person interacting with the system(s).
Business Process - Processes a command according to business rules and logic. Creates one or more domain events.
Command - A command executed by a user through a view on an aggregate that results in the creation of a domain event. For example, “Update Customer Address” or “Cancel Policy”.
Entity / Aggregate - Cluster of domain objects that can be treated as a single unit. For example, “Customer”, “Address”, or “Policy”
External System - A third-party service provider such as a payment gateway or shipping company.
These 7 building blocks are used in throughout the following four-step process.
Step 1 - Collect Domain Events
In the first step, Collecting Domain Events, each participant uses only orange Post-Its in the first round. Each orange Post-it stands for a business event, which is a technical relevant fact that happened in the course of business. The verb on the Post-it must therefore be in the past. As mentioned earlier, events must be in the past tense. This round is a pure brainstorming process about the existing domain events. This can take around an hour, but the facilitator will move the group along as needed.
At the end of this step, you wind up with a set of events agreed upon by all participants, both business and IT, that set the foundation for building out your services.
Step 2 - Refine Domain Events
The next step is to Refine Domain Events by going back through the events with the participants. Participants should be asked to clarify and explain what the events mean, and the events should be checked for syntactical correctness.
Events are also put order of time, gaps of events are filled as needed, and wording on some may be clarified or changed to fit. Synonyms (different terms for the same thing) should be unified and differences clarified if the same term is used to mean multiple things. Remember, though, this is just in the scope of a particular bounded context or business domain. We’re not trying to make unified definitions for everything, just the business case(s) in scope.
This step lands us with a refined set of events placed in chronological order, and sets us up for the next part.
Step 3 - Track Causes
Step three brings us to process modeling, where we track the causes of the various domain events. There are four main causes available: User actions (commands), External Systems, Time (Business Process), and other Domain Events via automated reactions. The goal in this step is to fill in all the causes or triggers of the events.
In our example, we have:
- Users issuing commands for ordering products, accepting offers, and checking out
- A gap in events that needed filled in around offers
- Multiple points of interaction with external systems
Finally, we can add in external systems we’ll need to interact with, such as webpages, origination systems, offer system, inventory, warehouse, and vendor payment processing systems. So now we have a clear picture of all the events that happen and what caused them.
Step 4 - Identify Aggregates and Bounded Contexts
And the last step involves adding the entities / aggregates to the model and arranging our stickies around them to make new relationships clear.
Bounded Contexts emerge in the final model, which are separate buckets of responsibility. BCs are a language boundary, meaning terms and sentences can mean different things depending on the context in which they are used, but MUST be used consistently and concretely within the context.
For example, we used to try to craft a universal, enterprise-wide definition of Policy when the reality is, Life Policy and Auto Policy are two different things because they exist in separate contexts.
How Does Event Storming Help with DDD?
Event Storming is just one approach to uncovering the elements of Domain-Driven Design listed above, and one of the most accessible in our experience. However, it's not the only approach. So Domain-Driven Design describes the pieces needed for architecting modern software, and Event Storming is one way to get there.
Hopefully, this gives you a flavor of how DDD and Event Storming help figure out which integration points should be APIs and which should be Event Streams. There are many other questions you can answer using Event Storming, so we would encourage you to explore the practice further.
Where Can I Find Out More?
Event Storming: The authoriative site.
Other approaches to Domain-Driven Design: