Domain-Driven Design — EventStorming
Overview
To implement the Tactical Domain-Driven Design in a proper way that fulfils business logic and requirements in software level (low-level), the stakeholders who are related to the specific business domain should get together and brainstorm about project features.
This meeting has a goal and it is building a productive communication between all project participants like product owner, software architect, QA, domain expert, front-end developers and back-end developers to find a feasible technical solution and understand each parties' language, mentality and attitude.
Such meetings or workshops that the team members from different parts of company partaking on designing a software proactively is named EventStorming.
It is a flexible workshop format for collaborative exploration of complex business domains. The adaptive nature of EventStorming allows sophisticated cross-discipline conversation between stakeholders with different backgrounds, delivering a new type of collaboration beyond silo and specialization boundaries.
— Alberto Brandolini, the inventor of EventStorming
Concerns & Definitions
Prior to starting, it is essential to decide carefully about the participants and colleagues that should join the workshop. Of course, at first glance, this could be a great opportunity for everyone in each team to cooperate in a project and build a software with high level of collaboration and partnership. But handling and leading a big group, regarding actively participation of all stakeholders, would be difficult.
Alberto Brandolini suggests:
Just keep in mind that the goal of the workshop is to learn as much as possible in the shortest time possible. We invite key people to the workshop, and we don’t want to waste their valuable time.
So, the size of workshop and number of participants is the first and most challenging concern and Vlad Khononov strongly suggests to keep the team size not more than 10 people.
Regarding my experiences, EventStorming can help you and your organization for various difficulties and challenges such as building a ubiquitous language, modeling a new business process, improving an existing business model or even when the domain is not an structured domain.
Remember, EventStorming is time consuming and time is money. Also, I have emphasized in introducing of Domain-Driven Design that not all the projects need the DDD and more precisely this workshop. So, as the second concern, I strongly suggest you to have a good reason, like the reasons that I have mentioned above, for doing this workshop.
Workshop Requirements
As mentioned, EventStorming is a workshop that the participants or stakeholders actively take part of it. To have the most productive and effective meeting, we need 3 tools as below:
- Play ground: An space to model the software based on its components, behaviors and events. If we make a workshop in person, a wall covered with white paper is suggested. Otherwise, some web-based software like Miro could be best option.
- Sticky notes: Different color of them describe the various aspects of business domain that will be discussed in next section.
- Marker: To write and draw the connections and boundaries.
Business-Domain Description
Beside play ground and marker that are described above, the sticky notes play the most effective and impressive role in this workshop. By means of them, that have different colors for various concepts, we can explain our business domain in details. The concepts and related colors are listed as below:
▹Aggregate: It is a group of objects (value objects and entities) that are gathered together in a single cluster.
▹ Domain Event: It is a message that describes events that has occurred in business domain or aggregate. (They have to described in past tense)
▹Policy: It could be a logical statement such as rules engine that has to make a decision(s) in case of defined conditions and happening domain events.
▹Command: To run some services in specific circumstances, the actor or even other services should send/generate command.
▹Actor: A person who executes a command to trigger or initiate a service.
▹External System: Every 3rd party software that are out of business model.
▹Question: Questions or bottlenecks in software from workshop participants point of view.
▹Read Model: Data from inside model for actor or user to get information as metadata about the process, domain events and so on.
EventStroming Workshop Steps
Each meeting, regardless of number of participants and complexity of business requirements, has 6 main steps.
- Define & Organize Domain Events: All possible events that could happen in the business should be written down on orange sticky notes and organized or prioritize by team member based on their understanding from requirements and preference of the business. We have to revise the domain events carefully and clean them up from playground (board) if they are irrelevant or useless. The pivotal events (The events that represent the transformations and domain changes) must be determined in this step.
- Describe Commands & Policies: What we need in this step is the reason to produce the domain events and define a destination for them. By commands (blue sticky notes), that are made by actors, these reasons could be fulfilled. On the other side, Domain events can be input for policies (purple sticky notes). Furthermore, the policies in event-stormed model will call one or more commands.
- Characterize the Aggregates: The aggregates in each bounded context, that can be at least one, are responsible to analyze the incoming commands and produce the expected domain events. On the other words, they are defining the logical dependency between commands (input) and events (output).
- Explain Read Models & Define External Systems: In this step we have to find out whether we can use 3rd party services or software to simplify our development phase. This is the place that we can be beneficiary from general solution (Generic Subdomains). Furthermore, the incoming data, like sequence of orders in E-commerce, shall be defined with green sticky notes.
- Illustrate Domains (Bounded Context): This part is nothing but gathering together the related aggregates and domain events in a same group or bounded context.
- Discuss Doubts and Ambiguities: As the last step, every participant has to put his/her questions and ambiguities on the playground written on red sticky notes beside the one that its description is not clear or even is risky to develop.
Case Study (Burger-Best)
To fully understand the EventStorming workflow and how to do it in an effective way, we investigate together a case study to illustrate the different domains in designing the online shop for a fictitious fast food company, Burger-Best.
The Burger-Best has only one store in downtown that wants to enlarge its business by providing an online ordering service for customers with free delivery to any part of city.
What makes these steps, in the figure above, more understandable and conceivable to implement by development team is the reconciling the high-level business description with code-base that will be achievable with EventStorming.
Define & Organize Domain Events
In Burger-Best that should provide possibilities of selling hamburger, each participant, Firstly, brainstorms about the events that can happen until the order is delivered.
Such domain events like “payment finalized” and “order delivered” can happen. But some of them play the key roles in event flow (Pivotal events). These events can be listed as below:
- Order Placed
- Online Payment Finalized
- Cooking Finished
- Order Delivered
Describe Commands & Policies
The domain events above need command or system defined policy to be produced. On the other words, in this step you have to find out the relation between domain events and specific command or policy. Furthermore, the commands that are produced by specific policy, should be defined.
For example “Cooking Hamburger Started”, in a traditional way, can be triggered by the chef (command) and in fully automatic way by the machine (policy).
Here, we have to design the traditional kitchen and delivery system, that’s why most of the domain events are triggered with command and people like driver, customer and chef.
Characterize the Aggregates
It is now the time to analyze the commands, policies and domain events and define the logic to realize the reason of their communication by means of aggregates. As it is mentioned in definitions, aggregates can be more than one in each bounded context.
The key point to define the number of aggregates in a domain is SOLID principles. Based on my experience, A comprehensive aggregate as God Class in bounded context can simply ended to “Big Ball of Mud”.
Explain Read Models & Define External Systems
In our event-stormed model, it is more efficient and economical if we use third party to handle online payment (external system). Furthermore, there is queue as read model for orders in kitchen and delivery part.
We can add more queues in model if:
- There is such a list of orders that should be processed.
- The analysis time of command/policy in aggregates is not the same, so one of aggregates have to wait for another one.
Illustrate Domains
Time to define boundaries!
In Burger-Best event-stormed model, we could define 4 aggregates that each can be heart of a bounded context as illustrated here.
You can even merge the “Online Payment Domain” and “Online Shop Domain” to a single bounded context. Remember that there is many designs for a project that could be chosen as final solution by participants.
Discuss Doubts and Ambiguities
Regularly, in real world event-stormed models that should fulfill the bunch of functional and non-functional requirements, we would have tens of bounded contexts and domains that bring many ambiguities and unclear points in the participants minds during workshop.
Wrapping Up
EventStorming, like other tools in Tactical Domain-Driven Design, is based on parties collaboration and team members cooperation to find ubiquities language and certain solution for a business requirement by all stakeholders.
Regardless of its complexity, it should be part of company culture and workflow of firms to achieve their goals in launching product to market in the right time.
