The objective of this article is to use the Event Storming for understanding the domain and for coming up with domain model for Subway (A fast food restaurant franchise).

The intention of this exercise to cover basic use cases. Please feel free to provide suggestions for improvements.

Event Storming

[Wikipedia] Event storming is a workshop-based method to quickly find out what is happening in the domain of a software program.

The business process is “stormed out” as a series of domain events and subsequent steps are followed that helps in identifying the aggregates and bounded context of the the domain.

Step 1 : Brainstorm with domain experts and write down the domain events.

At the beginning of the event storming session, domain experts can just add the events to the whiteboard and once all the events are added, these events can be grouped together in logical manner and can be sequenced accordingly to their timeline.

The following diagram demonstrates the outcome of this exercise.

Item vs Product

An Item is something that can be used for preparing Products like Meals, Sandwiches etc while a Product is something that can be bought by customers.

Step 2: Add the actors and commands to the domain events

The purpose of this step is to identify and write down the actors and commands. This step will helps in identifying different types of commands that can lead to same event as can be seen in following diagram for “Item Published” event.

After this step, it is recommended to narrate the domain stories using the Actors, Commands and Domain Events to ensure that all the domain events are captured.

Domain Story: Customer can browse through the products and then select a product of choice and add it to the cart. Customer can continue to browse, add and remove product from the cart. Once customer is done browsing then customer can start the checkout process.

Step 3 : Identify the Aggregate and Contextual Boundaries

<Q>Should Item, Product and Menu have their own bounded contexts or are they part of the same bounded context?

This is where deeper analysis is required for each of the identified aggregates to understand how tightly coupled they are with each other and whether they belong to same domain boundary or different.

The next few steps will help with this analysis.

Step 4 : Define the Aggregates, Entities and Value Objects

Catalog Management : Aggregate, Entity and Value Objects

Here, store owner need to know the item details before an item is added to Product. Similarly, store owner also need to know Product and it’s item details before adding it to Menu. Therefore aggregates like Item, Product and Menu can share the same domain boundary as their meaning remains unchanged even when actor is issuing different commands to the system.

Inventory Management — Aggregate, Entity and Value Object

Cart Management — Aggregate, Entity and Value Objects

Order Management — Aggregate, Entity and Value Objects

Promotion Management — Aggregate

The role of Item is different in different context — Catalog Management, Inventory Management, Cart Management and Order Management, hence the type of information that will be exposed and used in each context is going be different.

Domain Model — Boundaries, Aggregate etc.

References

• https://medium.com/capital-one-tech/event-storming-decomposing-the-monolith-to-kick-start-your-microservice-architecture-acb8695a6e61
• https://www.rubiconred.com/blog/event-storming
• https://ibm-cloud-architecture.github.io/refarch-eda/methodology/event-storming/