Domain-Driven Design Part II: Tactical Design

Published in

n11 Tech

7 min readMay 11, 2022

In part I of this article I tried to explain the strategic design phase of the domain-driven design and integration patterns. In this second part, I would like to share my understanding and knowledge about the tactical design phase of domain-driven design. If we compare two-phase, strategic design deals with abstract beings but tactical design deals with classes and modules. When passing from strategic design to tactical design, event storming is used to make the transition smooth. I will go through a simple example in order to best explain event storming and tactical design phases.

Scenario: There is a company and this company wants to sell its products on the internet and let’s assume that there are several functional requirements for this process. These are

Users should be able to give orders via an interface.
After the successful payment process, stock records should be updated for the specifically ordered product.
Products should be able to be registered to the system.
After registering a product stock record should be created for a specific product.
Product stock count should be updated.
Stock records should be able to query.

All these problems generate our domain. We have to granulate and split our domain into sub-domains. In order to find these sub-domains, event storming is used. Let’s look closer at what event storming is and then we will split our problem space, which is explained above, into sub-domains.

Event Storming

Event storming is a communicative and visualized brainstorming method. The aim is to identify different areas that need specific knowledge and expertise (sub-domains), specific sub-domain related events, and aggregates that encapsulate sub-domains and their behaviors in themselves. (Example workshop here)

Who should be involved?

It’s important for an event storming workshop to have the right people present. This includes people who know the questions to ask, typically developers, and those who know the answers such as domain experts, and product owners.

Preparation

Decide which area of knowledge you want to model or understand. The more extensive the business process, the more time the event storming session takes.

Think about whether you can divide and elaborate the knowledge area into smaller business processes, which you model one after the other in several event storming sessions.

Example:

Knowledge area — online shop

Business processes — After registering a product stock record should be created for registered product.

Event storming sessions need a good facilitator which is chosen from agile coaches or scrum masters. The obligation of this person is to prevent meeting out of box arguments.

Terminology

During event storming sessions participants use different colored post-its. Each color has a different meaning let’s look at these.

Considered as a message that provides communication with internal modules or external sub-domains. An event occurs in the business process. Written in the past tense.

A person who executes a command through a view.

Processes a command according to business rules and logic. Creates one or more domain events.

A command executed by a user through a view on an aggregate results in the creation of a domain event.

The cluster of domain objects can be treated as a single unit.

The aggregate is created, retrieved, and stored as a whole.
The aggregate is always in a consistent state.
The aggregate is owned by an abstract structure called the aggregate root, whose ID is used to identify the aggregate itself. Aggregate root obligation is to manage the domain event's life cycle.

A third-party service provider such as a payment gateway or shipping company.

A view that users interact with to carry out a task in the system.

Unclear topics or questions that arise during the session.

Event Storming Steps

Up to now, I tried to share my knowledge on what event storming session is and their participants. Now I am going to explain its steps and implement these steps in my example given above.

Collecting Domain Events

Each participant uses orange post-its in order to define domain events. An event occurs in the business process. The verb on the post-it must be in the past tense.

2. Refine Domain Events

Check the Domain Event post-its with the participants and ask participants to explain what each event means. Also, discuss again whether the events are in the right order in terms of time.

3. Track causes(Process Modelling)

Argue with other participants where do the events come from? Ask about the triggers of the events such as commands, external systems, and business process etc. In this step most closely sub-domains have appeared. When identifying subdomains and their borders we should think of several things

Is there a property that corresponds to different meanings in different sub-domains?. For example, a product corresponds to a property that has quantity in Stock Subdomain however, in the Shipment subdomain it corresponds to a shipment to post.
If a change need often appears in a subdomain when you change an aggregate state belonging to another specific subdomain we may think to combine these two tight coupled subdomains in one more abstract subdomain.

4. Re-sorting & result(Software Modelling)

Now remove the post-its from the timeline and group them around the sub-domains found and identify aggregates. This makes the following questions clear:

Which users trigger which commands?

Which commands affect which aggregates or external systems and triggers which changes?

Which aggregates or external systems trigger which events during command processing?

Which events trigger which policies (business processes)?

Which events create which read models for which use cases?

Which policies call up which new commands?

We have discussed the event storming session’s steps. Now I would like to argue the requirements below;

1- After registering a product stock record should be created for a specific product.

2- Stock records should be able to query.

To briefly mention first requirement , as we can see from the image above, Product and Stock subdomains are different microservices. When a product is registered from the Product subdomain, the stock record for this product has to be created in the Stock subdomain. However, how the Stock subdomain will be informed?

There are several communication types for this which are;

Synchronous Communication (directly call rest endpoint or gRPC endpoint)
Asynchronous Communication (transactional outbox pattern, saga, message queues)

we can use one of two solution with respect to our need.

Let’s analyze second requirement. We can directly put this endpoint in stock microservice. However if think from the different perspective, CRUD abbreviation’s R (read) represent Query operation. Others (CUD) represent create, update and delete operations. CUD operations always affect aggregate’s or entitiy’s state however read operation does not affect aggregate or entity state, it is just all about getting changed state. If we look these operations from the coupling perspective, we must take into account separate concerns and avoid overloading stock microservice with too many responsibilities. To be more clear, Open Stock Command, Increase Stock Command, Decrease Stock Command, Close Stock Command end points can be served from one service and Query endpoint can be served from another service. This approach is called as Command Query Responsibility Segregation Pattern (CQRS) which is introduced by Greg Young.

According to this principle; Every method should either be a Command that performs an action or a Query that returns data. A command cannot return data and a query cannot change the data. State changes occured in command side is carried to the query side over a message queue and persisted in order to be queried.

CQRS can be combined with another pattern which is called event sourcing. Basically, event sourcing is to store domain events, which are produced by aggregate behaviors, in a db called event store. Stored events in event store have to be chronological order, immutable and can not be changed. So, fetching all these events by aggregate id and replaying over aggregate we can achive latest state of the aggregate.

Up to now, I tried to basically discuss on communication types in microservice environment and also basically analyze cqrs pattern via relationship between product subdomain and stock subdomain example.

In order to keep things clean and does not to be messy, I am concluding. Next series I will continue to share my understandings.

Thanks for read. :)

Domain-Driven Design Part II: Tactical Design

References

Written by Can Güt