How do you transition from event storming to DDD tactical design and implementation?

1 What are policies?

Policies are the rules and constraints that govern the behavior and interactions of the domain entities. They define what can or cannot happen, when, how, and by whom. Policies can be explicit or implicit, formal or informal, simple or complex. For example, a policy can be a regulation, a contract, a business rule, a workflow, or a decision table.

2 How to discover policies with event storming?

Event storming is an effective visual and interactive tool for capturing domain events, commands, aggregates, and bounded contexts. It also helps you uncover the policies that trigger or constrain the events and commands. To do this, you can use different colored sticky notes or symbols to mark them on the event storming board. Additionally, asking questions like “What are the conditions or criteria for an event or command to occur?”, “What are the consequences or outcomes of an event or command?”, “Who are the actors or roles involved in an event or command?”, and “How are the events and commands related or sequenced?” can help you gain further insight into the policies.

3 How to validate policies with event storming?

Once you have identified the policies with event storming, you need to validate them with the domain experts and stakeholders. Different techniques can be used to check the validity, completeness, consistency, and clarity of the policies. For example, you can ‘play the timeline’ by walking through the event storming board from left to right and simulating scenarios and use cases. You can also challenge the policies by asking questions such as ‘why’ or ‘what if’ in order to uncover exceptions, contradictions, gaps, and ambiguities. Additionally, you should prioritize the policies according to their importance, urgency, feasibility, and value; focusing on the most critical and valuable policies first.

4 How to translate policies into DDD building blocks?

After validating the policies with event storming, you can translate them into DDD building blocks. These elements help design and implement the domain model. Domain events are facts or occurrences in the domain that have business meaning, and can be triggered or constrained by policies. Aggregates are clusters of domain entities with a consistency boundary and root entity, which enforce policies affecting state and behavior. Domain services are stateless operations that coordinate or perform domain logic not belonging to any aggregate, and can implement policies involving multiple aggregates or external systems. Sagas manage long-running transactions or workflows across multiple aggregates or bounded contexts, and can handle policies requiring coordination, compensation, or retries.

5 How to test policies with DDD building blocks?

After translating the policies into DDD building blocks, it’s essential to test them to ensure they work as expected and fulfill the business requirements. To verify the policies at varying levels of abstraction and granularity, you can use unit tests, integration tests, and acceptance tests. Unit tests verify the behavior and state of a single DDD building block in isolation. Integration tests check the interactions and collaborations between two or more DDD building blocks. And acceptance tests assess the end-to-end functionality and usability of the system from the user's perspective.

6 Here’s what else to consider

This is a space to share examples, stories, or insights that don’t fit into any of the previous sections. What else would you like to add?