Learning about your systems by writing code is a very expensive way to understand and refine the business processes involved. Building software ultimately requires a group of people to come together and build complex systems using their unique talents. The first step is understanding reality, which is easier said than done when reality is a complex software system that spans multiple disciplines and teams.
The challenge is how those people arrive at a shared understanding of what they are building. Software becomes expensive to change when teams implement behaviour without a common understanding of how critical business flows operate in practice. If product, engineering, operations, and other stakeholders encode different assumptions, the system begins to reflect those inconsistencies.
How do we solve this gap? There is a large difference between totally informal vibe coding and rigorous spec-driven development. Vibing will never produce systems of substance, while spec-driven development can introduce early barriers to communication through formalism. Event Storming is the sweet spot between the two, geared to rapid communication rather than formality.
Event Storming is a workshop format that brings product, engineering, operations, and domain experts around the same business flow. It exposes missing cases, policy conflicts, and boundary errors before those errors become software.
This series explains how to model a business process, derive software structure from that model, and keep system behaviour clear as the implementation evolves.
This series covers the practical techniques for doing this work.
- Part 1 makes the case for why modelling before building matters and introduces the formal principles that guide the rest of the series.
- Part 2 introduces Event Storming, a lightweight workshop technique for surfacing the events, commands, and policies that drive a business process.
- Part 3 covers how Domain-Driven Design turns Event Storming output into bounded contexts, subdomains, and domains.
How to Build Software That Stands the Test of Time
Intentional design means addressing two distinct questions. The first is whether the system does the right thing. These are functional requirements: the features, workflows, and business rules the system must support. The second is whether the system does it in the right way. These are non-functional requirements: reliability, observability, security, performance, maintainability, and auditability.
Two structural failures have compounded over the last fifteen years that make it challenging to build the right thing in the right way at any kind of large scale.
- Agile practices replaced upfront design with emergent design, but emergent design in practice means architecture is discovered under delivery pressure rather than specified with intent. Scrum-based workflows optimize for hitting arbitrary time boxes, not for building systems that stand the test of time.
- The cultural emphasis on shipping features means non-functional requirements are perpetually deferred. They are acknowledged in sprint planning, deprioritized against visible features, and inherited as technical debt by whoever maintains the system next.
The result is visible in the industry. Software written in the 1970s, 1980s, and 1990s often still runs in production across the world. Earlier developers were not necessarily smarter. Their development processes gave design more weight relative to delivery velocity. For all the hate waterfall receives, it created enough space to think before coding. We have lost that breathing room, and the software we build today is far more complicated. That combination is the problem.
Defects discovered after release can cost up to 30 times more to fix than defects caught during design and architecture.
If the entire group of stakeholders required to build something complicated cannot agree on what they are building, no amount of technology will save that software. Jumping straight into detailed specifications can itself be part of the problem. Specifications written in isolation by architects or business analysts often miss the reality of how the business actually operates.
There is a messy middle between business intent and technical implementation where misunderstandings live, assumptions go unchallenged, and requirements silently diverge from reality. This series aims directly at that messy middle.
What Is a Domain Model?
A domain model, through the lens of Domain-Driven Design (DDD) and Event Storming, is a living, evolving map of the problem space. It is the shared mental model between technical and domain experts that captures what the system is about.
In DDD, the model is expressed through aggregates, entities, value objects, and domain events, all aligned with the ubiquitous language. Event Storming brings this model to life collaboratively and visually by surfacing domain events first, then teasing out commands, actors, and aggregates that produce or respond to those events. The result is a collection of strategic artifacts that align implementation with business intent and reveal where behaviour, state, and decisions truly live.
Every system passes through phases of maturity, and the priorities at each phase are different. The emergent phase is the beginning. The team is small, the domain is unclear, and the goal is to prove viability. Speed matters more than structure. The evolving phase is where most production systems live. The team has grown, the system serves real users, and the cost of mistakes has increased. Structure needs to catch up with complexity. The mature phase is where the system has become a critical asset. Multiple teams maintain it. Stability, auditability, and predictability are essential. Changes must be modelled carefully.
The following table maps five priorities across these three phases.
Event Storming and formal domain modelling are most valuable in the evolving phase. In the emergent phase, the team is small enough that everyone shares full context. Formal modelling can feel like premature optimization when three people in a room already agree on what they are building. The sweet spot is multi-disciplined teams, potentially spanning multiple lines of business, that are sorting out a new opportunity, a new process, or modernizing a legacy system. That is where misunderstandings between stakeholders become expensive and where structured communication pays for itself.
If your system is in the mature phase but you find yourself doing heavy domain modelling, that system may not be as mature as you think. It may be going through a modernization or a significant expansion, and should be treated as evolving for the purposes of design.
| Priority | Emergent Phase | Evolving Phase ★ | Mature Phase |
|---|---|---|---|
| Accuracy | Capture enough logic to prove viability, sometimes at the expense of correctness. | Refine models to better reflect real-world behaviour. Teams understand the business but live in silos. | Maintain consistency with current business reality without introducing drift. |
| Sociotechnical Alignment | Fast, informal collaboration. One team, one codebase, shared context. | Cross-team coordination begins. Boundaries and ownership need to be formalized. | Hand-offs, documentation, and shared understanding must be explicit and resilient. |
| Sustainability | Prioritize delivery speed. Flexibility matters more than structure. | Introduce structure to support reuse, observability, and safe change. | Emphasize resilience, traceability, and explainability for long-term viability. |
| Risk Tolerance | High tolerance for breakage. Fast iteration and frequent change. | Reduced tolerance. More stakeholders, more surface area. Customer scrutiny and potentially regulatory scrutiny begins here. | Very low tolerance. Stability, auditability, and predictability become essential. |
| Change Strategy | Ship and adapt. Changes are cheap and fast. Fossilizing decisions is dangerous. | Design with reuse and extensibility in mind. Throwing away early prototypes begins, which can be the trigger for modelling. | Model changes carefully. Preserve causality, intent, and historical traceability. Refine, don't rewrite. |
Even if we model today’s business perfectly, tomorrow’s business will change. A system built for a global supply chain may face new tariffs that disrupt logistics, margins, and even the business model itself. In the early stages, systems can tolerate that kind of shock. But as they evolve and mature, the cost of change increases unless they have been designed to adapt.
In the next part, we get practical. Event Storming gives us a way to get everyone in the same room, surface the events that drive the business, and build a shared understanding of how those events relate to each other. It requires no special tools, no software, and no technical expertise from participants. Just sticky notes, a wall, and a willingness to communicate.