Practical DDD: Breaking Free from Theory — 1) Big Picture Event Storming

I would like to share my experiences while proceeding with Domain Driven Design(hearafter DDD), and the insights I have gained from them.

Before diving into the main topic, to explain the DDD I experienced, I am following the original methodology of the DDD(Eric) and Event Storming(Alberto).

A point to address before getting into the core details

In the past, I have carried out several projects under the title of DDD. Among them, the majority of DDD practiced in previous projects has become popularized through the content spread by the Pivotal. This specific DDD is what triggered my infinite exploration of the subject. This is because it seemed to be nothing more than a hollow solution. While it shouts the slogan of “Domain-driven Design,” it ultimately shows a methodology confined to the solution space only. The actual essence of EventStorming is missing — only the form remains, and every procedure exists merely as a prelude for TO-BE System Design. This clearly deviates significantly from the original intent of DDD. The core of DDD is to accurately understand our current system and provide a sustainable solution based on that understanding. On the other hand, if we become too immersed in theory, we often encounter cases where practicality or realism is severely lacking. We must also take into account the time and cost consumed by this DDD process.

Therefore, I intend to ignore the existing DDD methodologies and explain using what I consider the most meaningful DDD based on my experiences.

Tips for Big Picture Event Storming

When explaining based purely on the Big Picture Event Storming covered in the book, I believe every phase — from the “Kick-Off” to the “Pick Your Problem Phase” phase — conveys very significant meaning. I will describe the feelings and points to be cautious of for each stage.

Division of Roles

According to the literature, roles in a DDD Workshop are categorized as follows:

1. Facilitator: Responsible for the overall progress of DDD. In each phase, the facilitator should guide participants on where to focus and, if things aren’t going smoothly, change the atmosphere.
2. Supporter for Facilitator: Sometimes the facilitator can be misaligned with the overall process or the workshop facilitation may not run smoothly. You need to help them with that. The supporter should assist the facilitator in ensuring the overall event runs smoothly.
3. Narrator: This role is for verifying that all participants have understood the steps that require an overall explanation, like an explicit walk-through. The Narrator explains based on their own understanding.

The above are the official roles, but in practice, things do not proceed exactly as defined. This is especially true for the Facilitator role. I also tried to facilitate the overall process from a neutral standpoint of Event Storming, but there were limits. Regarding the “Out-Box” perspective — explaining the methodology, such as the rules and goals of each phase — it is appropriate for someone who fully understands the DDD process and has experience to act as the Facilitator. However, in the “In-Fight” area — which involves continuous questioning and challenging in terms of the ability to understand the flow of the defined domain events — it is difficult to lead unless you actually know the business. In my case, to address this, I had the person who knows the business best play a key role in drawing the overall flow. Of course, I am aware that this is not what Event Storming originally intended, because if someone dominates too much, others are likely to remain silent. However, reality is different. Unless it is someone who knows the business, it is realistically difficult for anyone to even get the process moving.

Sticky Notes

The following sticky notes were used. The way we proceeded was quite different from what is recommended in the book. While I believe Commands and Policies are not strictly necessary at this stage, I have no major objections to including them; it doesn’t hurt to have them.

Workshop

Below, I describe my observations and tips for each stage.

Step1. Kick Off

• It is beneficial to have someone provide even a brief explanation of the business we are analyzing.

Step2 — Phase 1. Chaotic Exploration

• Go directly to Phase 2 or Phase 3. In fact, simply laying out Domain Events and then repeating Phases 2 and 3 afterward is somewhat inefficient. It is wiser to proceed by adding the Actor and System immediately.
• Emphasize the* definition of Domain Event**. It is crucial to clearly define what constitutes a domain event from the start.
• Actively utilize a Glossary with *Ubiquitous Language**. Ensure that terms used are consistent and documented to avoid ambiguity.
• When silence occurs, an icebreaker is needed: The facilitator must intervene to revitalize the discussion when participation stalls.
• Expecting to have locally ordered clusters in a disordered whole, and the timeline constraint to be broken in a few places. Do not worry about perfection at this stage. It is normal for the timeline to be fragmented. No problem — we’ll sort out this mess in the next step.

Step2 — Phase 2. Enforcing the timeline

• With Pivotal Events we start looking for the few most significant events in the flow
• Wouldn’t spend much time looking for a perfect choice of pivotal events

Step2 — Phase 3. People and System

• Many business discussion will occur in this phase.
• This is a moment when the facilitator’s leadership skills are crucial. If there is no leadership to cut off *long discussion**, this phase will takes a lot of time to define aligned version.

Step2 — Phase 4. Explicit walk-through

• Verification all attendees clearly understand overall process.
• If there is unclear information for narrator’s perspective, can ask to attendees.
• While the narrator’s on stage, the facilitator should make sure that the spoken storytelling is aligned with the model: missing events or systems can be added on the fly.

Step2 — Phase 5. Problems and opportunities

• Nothing to comment.

Step2 — Phase 6. Pick your problem

• This part is not so much for the current Event Storming session itself, but rather will serve as a guide for decision-making that may arise in the future TO-BE system.

Domain Events Must let participants know the definition of “Domain Event” These events are used to capture changes that can trigger further actions or state changes in the system. * To avoid physical event, technical term, condition-like event

Ubiquitous Language Keep people use same ubiquitous language. (In the real world, business terms usually become the ubiquitous language) People in workshop usually under-estimate to sync-up Ubiquitous language between participants.

**Long Discussion

• **Don’t need to discuss for too “rainy” scenarios. If you really want to express it, an additional sticky note will suffice. There’s no need to explore scenarios for extremely unlikely situations, such as when my ticket is missing or a booking number is absent in a reservation list.
• If the objects differ but the process is the same, it can actually be replaced by a single Domain Event story.
• Keep people use same ubiquitous language.

Pain Points

1. Lack of proper timeboxing for all discussions. And the branching scenario may not perfectly handle this time. → Sunny Scenario mainly, avoid too much rainy Scenario.

2. Insufficient focus on “TOBE” discussions. Participants attention wanes over time. → TOBE events flow and system updates sometimes needed.

3. Discussions often go off-scope or are at the wrong abstraction level → If the time duration takes too much time, keep it into the parking lot