How do you align your event storming outcomes with your DDD strategic design and bounded contexts?

To define domains and subdomains, we start with a domain business canvas model (it is like business canvas model), engaging with domain business leaders to align expectations. During the event storming big picture workshop, we identify domain-subdomain relationships and related products. This collaborative process ensures each subdomain serves the broader domain's strategy, streamlining development and enhancing solution effectiveness. Our methodical approach ensures clear communication and efficient process design across domains.

Understanding your core domain and subdomains is key to focusing on what makes your business unique. During Event Storming, I start by identifying the key events that capture your business’s value, as they often highlight the most critical areas. To clarify the distinction between core and supporting domains, I use color coding (e.g., red for core, blue for support), cluster related events, and prioritize based on business value. This helps identify where your competitive advantage lies. I also leverage tools like the Purpose-Based Alignment Model and Context Distillation to refine the process.

To identify bounded contexts and create a context map, we conduct process modeling post-event storming to visualize workflows. We define boundaries for each context, detailing inbound-outbound communications, and rules on bounded context canvases. These canvases guide microservice development. Through context mapping, we illustrate interactions and dependencies between contexts, defining integration strategies. This structured approach ensures a clear, efficient system architecture, facilitating smooth interactions across our microservices landscape.

In my experience, we align domain events with aggregates by first identifying critical business events during event storming, then defining bounded context and aggregates of each bounded contexts that encapsulate related entities and value objects. We meticulously align each event with its corresponding aggregate, ensuring they reflect business processes accurately. This process includes modeling aggregates to enforce business rules and iteratively refining their alignment with events. This method creates a coherent, business-centric model, ensuring data integrity and consistency in our system.

We often think about the system's behavior in terms of the IO's behavior. We forget that behind that interface, there is a model—a sophisticated set of data structures and functions—driving it. More importantly, that model does not need the interface. It would execute its duties, modeling all the events in the system without the system ever being displayed on the screen. The interface does not matter to the model. This is the ground rule for defining aggregates and related domain events.

Properly defining aggregates and bounded contexts is crucial to accurately determining service sizing (micro, mini, macro). A microservice should manage one aggregate, though it can handle multiple if they are highly cohesive. This strategy maintains clear boundaries and cohesion within services. Additionally, considering non-functional requirements such as scalability, resilience, and resource needs (throughput, CPU, memory, etc.) during decomposition is vital to ensure the architecture's robustness and adaptability for future demands.

Event storming on DDD Design requires a strong governance model that should fit in enterprise SDLC steps. There should be review points like business review, architecture review or ddd quality reviews. And theese steps should be in business as usual sdlc flow as a jira or other project management tool. ?f it is not correctly designed or alligned with stakeholders there should be iterating steps.