Domain Driven Design & Event Storming — A Practitioners’ Guide to Overcoming Misconceptions & Objections
Section 1 : Domain Driven Design — Common Misconceptions
1. DDD is just about modelling the domain:
While domain modelling is a key aspect of DDD, it’s not the entirety of the approach. DDD is a broader philosophy and set of practices that go beyond just modelling the domain. The underlying principles that DDD emphasises include Encapsulation, Single Responsibility, Independent Deployability, Separation of Concerns, Loose Coupling, High Cohesion etc.
2. DDD is only applicable to large, complex systems:
DDD principles and techniques can be applied to projects and systems of any size, not just large, enterprise-level applications. But apply it carefully so that there is a return of investment for costs involved in learning and practicing.
3. DDD is only about the Ubiquitous Language:
The ubiquitous language is an important aspect of DDD, but it’s not the sole focus. DDD encompasses other key elements like bounded contexts, aggregates, and the overall strategic design of the system.
4. DDD is just about the Domain Model:
DDD is not just about the domain model. It also emphasises the importance of the overall architecture, the software development process, and the collaboration between developers and domain experts.
5. DDD is all about the technical implementation:
While DDD does have technical aspects, such as the design of the domain model, it’s not solely focused on the technical implementation. It also emphasises the importance of understanding the business domain and aligning the software with the business needs.
6. DDD is a replacement for existing software development methodologies:
DDD is not a replacement for other methodologies like Agile or Waterfall. Instead, it can be integrated and used alongside these approaches to enhance the overall software development process.
7. DDD is a set of strict rules that must be followed:
DDD is more of a set of principles and guidelines, rather than a rigid set of rules. The application of DDD should be tailored to the specific needs of the project and the organization.
8. Bounded Context equals a Single Database:
Bounded context defines a boundary within which a particular domain model is consistent. While a microservice can align with a bounded context, it’s not always the case. A bounded context is a conceptual boundary, not necessarily a deployment unit. It may represent one or more microservices, but it could also exist within a monolithic application.
9. Aggregates equal to Tables in Data Model:
A domain model is not just a data representation; it’s a behavioural model that reflects the business logic and rules of the domain. It’s meant to capture how the system behaves and how business processes work, not just how data is structured in the database. The data model might be derived from the domain model, but they are separate concepts.
10. Aggregates are just collections of Entities:
Aggregates are not just a group of related entities; they represent a consistency boundary within which all changes should be atomic. An aggregate ensures that business rules are consistently followed, and the relationships between entities within the aggregate are maintained. The root entity controls access to the aggregate and ensures that the state transitions are valid according to business rules.
11. Ubiquitous Language is just Terminology:
Ubiquitous language is much more than shared terminology. It’s about creating a shared understanding of the domain among all stakeholders and ensuring that this language drives the design. This language should influence code, conversations, documentation, and decisions, ensuring that everyone — from business to tech — has a common and deep understanding of the domain.
12. Event Sourcing equals DDD:
Event sourcing is just one way of storing data, where the state of the system is reconstructed from a series of events. While it fits well with certain DDD concepts (like domain events), event sourcing is not a requirement for DDD. You can implement DDD without event sourcing. The key in DDD is to capture the domain’s complexity through models and behaviours, not necessarily through how data is persisted.
13. Tactical Design is all you need in the end:
Tactical design is only part of DDD. Strategic design — that is defining bounded contexts, managing the relationships between them, and aligning the system with business goals — is just as important, if not more so. Without strategic design, you risk creating fragmented or inconsistent models across teams, leading to a “big ball of mud.”
14. DDD creates overly complex models:
DDD is about simplifying complexity, not adding unnecessary complexity. The domain model should be as simple as possible, but no simpler. Focus on core domains and simplify less critical subdomains using generic solutions or off-the-shelf software. DDD doesn’t mean over-engineering every part of the system.
15. DDD is waterfall:
DDD encourages iterative and incremental development. You should evolve your domain model as you learn more about the business and the problem domain. It’s not about perfect upfront design but about continuously refining and improving your model based on feedback and new insights.
16. DDD can not be used with Non-Object Oriented languages:
While Object-Oriented languages provide natural support for many DDD principles, such as encapsulation, inheritance, and polymorphism, DDD can also be effectively applied in the context of non-Object-Oriented languages. For example: data structures and procedural logic in C or functional constructs in Haskell or Clojure.
Section 2 : Domain Driven Design : Objection Handling
1. Too complex:
DDD is best suited for complex domains with a high degree of business logic and complexity. For simpler projects, the complexity of DDD can outweigh its benefits.
2. Steep learning curve:
Successful adoption of DDD requires proper training and incremental learning. Teams should focus on understanding the strategic value of DDD before jumping into tactical patterns.
3. Too much upfront investment:
DDD works best in long-term, iterative processes where the complexity is high, and early investment leads to long-term gains. It’s important to set realistic expectations regarding the upfront effort and the eventual return on investment.
4. Technical over-engineering:
Proper DDD implementations should balance both strategic design (domain partitioning, bounded contexts) and tactical design (patterns for implementing domain logic). The strategic design should guide the system architecture, while tactical design ensures correct implementation within those boundaries.
5. Modelling at the expense of delivery:
DDD should be practiced in an iterative manner. Instead of trying to model everything upfront, teams should aim for incremental improvements to the model as the software evolves, focusing on delivering value early and refining the domain understanding over time.
6. Not aligned with agile practices:
DDD can complement agile if done properly. Strategic design should align with agile’s iterative process, where domain models are developed over time and refined based on feedback. DDD requires a mindset shift, where domain knowledge is continuously updated as new information comes to light.
7. Might result in Inconsistent application across teams:
DDD must be applied with strong cross-team collaboration and regular context mapping exercises to ensure that teams have a consistent understanding of domain boundaries, language, and concepts.
8. Resistance to change due to existing methods:
Japan Team example — Follow Modular monolith after Domain Modelling
9. Lack of domain experts:
Finding and engaging true domain experts who can effectively collaborate with developers is often a significant challenge. The current documentation in terms of user stories or use cases and reverse engineered document from source codes (using the GenAI assistants) would serve as a good proxy. But it is important to have a business stakeholder present that can confirm the understanding and explain the upcoming changes to the business processes/requirements.
10. Lack of tools:
There is a lack of mature, widely adopted tooling to support the DDD process and patterns. This can make it harder to adopt and apply DDD effectively. In the future, GenAI assistants would be able to fill the tools gap to generate diagrams and documentation and keeping them in sync.
11. Silver-bullet fallacy:
DDD is not a silver bullet. It’s a methodology best suited for complex domains with intricate business logic. It requires commitment, proper facilitation, and domain expertise. Teams should assess whether the complexity of their domain warrants the use of DDD.
Section 3 : Event Storming — Common Misconceptions
1. Event Storming is just a brainstorming session:
Some people think Event Storming is simply a general brainstorming session where ideas are thrown around without structure. Event Storming is a structured approach to domain discovery, evolving around modelling domain events — the significant things that happen in the business domain. It uses a clear framework for how events, commands, policies, and actors relate to one another in the system.
2. Event Storming is only for Developers:
Some believe Event Storming is a technical exercise intended only for software developers.
Event Storming is meant to include cross-functional participation from various stakeholders, including domain experts, business analysts, designers, and developers. It’s most effective when people with different perspectives (both technical and non-technical) contribute, as this enables a shared understanding of the business domain.
3. It’s only useful for new Projects:
Many think that Event Storming is only useful when starting a new project and that it’s not helpful for existing systems or legacy projects. Event Storming can be highly beneficial for existing projects, especially for understanding legacy systems or discovering opportunities for improvement. It’s a tool for gaining insight into the current domain, identifying bottlenecks, and aligning everyone on how the system works, whether it’s a new or existing project.
4. Event Storming is a one-time activity:
Some assume that Event Storming is a one-off session and that once it’s done, no further exploration or iteration is needed. Event Storming is an iterative process. As teams discover more about the domain, further sessions are often necessary to refine the model, explore new events, or revisit decisions. It’s a technique that evolves along with the project and the team’s understanding of the domain.
5. It’s all about Post-Its and Sticky Notes:
People sometimes reduce Event Storming to just placing sticky notes (Post-Its) on a wall to map out events. While sticky notes are a useful visual aid, Event Storming is much more than just arranging them. The core value lies in the conversations, collaboration, and insights that happen while mapping out the events. The goal is to extract deep domain knowledge through dialogue and exploration.
6. Event Storming Is the same as Event Sourcing:
Some confuse Event Storming with Event Sourcing, a specific technical pattern for persisting state changes as a sequence of events. Event Storming is a domain modeling technique that can be used to understand business processes, while Event Sourcing is a persistence strategy for storing data. While they both deal with events, Event Storming is about discovery, not about how to technically implement event-based persistence.
7. It’s only for Domain-Driven Design (DDD):
Many assume Event Storming is exclusively for Domain-Driven Design (DDD) projects. Event Storming is a versatile technique that can be used in various contexts outside of DDD. It’s a way to explore and understand complex business processes, regardless of whether the team is practicing DDD. It’s useful in any domain where business events drive the process, such as product design, process re-engineering, or even organizational change.
8. Event Storming is a Technical Design session:
Some believe Event Storming is purely for technical design and that its main purpose is to map out the technical architecture of a system. Event Storming is about understanding the business domain first and foremost, rather than jumping into technical solutions. While it can help inform technical design decisions later, its primary focus is on the business events, processes, and rules. The technical details can come later, once a shared understanding of the domain is established.
9. Everything must be perfect and precise:
There’s a belief that everything in an Event Storming session needs to be perfectly organized and that mistakes or incomplete ideas should be avoided. Event Storming is intended to be exploratory and informal. The purpose is to discover the domain and its events in a collaborative way, which means the process can be messy at times. Precision is not the goal in the initial phases; it’s more about surfacing insights and areas of misunderstanding. You can refine the model later as more is understood.
10. It’s a sequential, Waterfall-like process
Some think Event Storming must follow a linear process where events are mapped out in a strict sequence without revisiting previous decisions. Event Storming is inherently iterative and non-linear. Events don’t need to be mapped out in perfect order from the start, and the process often involves revisiting and reworking previously defined events. It encourages experimentation and discussion, allowing for adjustments as new insights emerge.
11. All Events must be mapped out in detail
There’s a tendency to believe that during Event Storming, every single event, command, policy, and actor must be detailed from the start. The goal is not to capture every single detail in the first session. Event Storming aims to create a high-level understanding of the domain. Once you identify the critical events and processes, you can dive deeper into specific areas that require more attention later on. It’s about exploring the most important parts of the system first, rather than modelling every minor event in extreme detail.
12. Event Storming is only useful for Developers
Many believe that Event Storming only benefits developers and that business stakeholders don’t gain much value from the process. Event Storming is designed to bridge the gap between technical and non-technical stakeholders. It provides value to business stakeholders by helping them clarify their understanding of the domain, expose hidden assumptions, and identify opportunities for optimization. It’s a tool for everyone involved in the domain, not just developers.
13. Event Storming is limited to Software Development
Event Storming is sometimes seen as only applicable to software development and specifically for modeling event-driven architectures. While Event Storming is highly effective for software development, it can also be applied in non-software domains. It can be used to map out business processes, explore organizational structures, and identify pain points in workflows. The focus is on understanding events and processes in any context, not just in software.
14. Event Storming results in a finished Domain Model
Some expect that after one Event Storming session, the team will have a final, complete domain model that won’t need further refinement. Event Storming is a discovery tool, not a one-step solution for creating a final model. It’s about exploring the domain and gaining a shared understanding, but the model will likely evolve through further conversations, sessions, and iterations. The output of Event Storming is usually an incomplete but valuable starting point that can be refined.
15. Event Storming can be done without facilitation
Some teams believe they can run an Event Storming session without a facilitator or with minimal guidance, leading to a lack of structure. A skilled facilitator is crucial to the success of an Event Storming session. The facilitator helps guide the conversation, ensures that everyone participates, manages time, and refocuses the group when discussions go off track. Without proper facilitation, the session can become chaotic or lose focus, resulting in limited insights.
Section 4 : Event Storming — What can go wrong & the Fixes
1. Lack of clear business context and domain knowledge:
Participants may not have a deep understanding of the business domain and processes, leading to incomplete or inaccurate event identification.Ensure you have the right mix of business experts and domain knowledge owners participating in the event storming session. Spend time upfront to establish the business context and boundaries.
2. Overwhelming number of events:
Participants may generate too many events, leading to cognitive overload and difficulty in organizing and making sense of the flow. Encourage participants to focus on the most critical and high-level business events first. Periodically review and group related events to keep the model manageable.
3. Difficulty in establishing the proper sequence of events:
Participants may struggle to correctly order the events in the right chronological sequence. Provide a clear visual timeline or swimlane to help participants place the events in the right order. Leverage the business domain experts to guide the sequencing.
4. Lack of consistent language and terminology:
Participants may use different terms or vocabularies to describe the same concepts, leading to confusion and ambiguity. Encourage the use of a ubiquitous language and facilitate a discussion to align on the right terms and definitions. Maintain a glossary of agreed-upon terms.
5. Difficulty in identifying the right level of abstraction:
Participants may struggle to strike the right balance between high-level, abstract events and overly detailed, technical events. Guide the participants to focus on the essential business events and avoid getting caught up in the technical implementation details. Revisit the level of abstraction periodically.
6. Lack of engagement and participation:
Some participants may be more passive or reluctant to contribute, leading to a skewed or incomplete model. Foster an inclusive environment, encourage active participation, and ensure that all voices are heard. Break the group into smaller teams if necessary to increase engagement.
7. Difficulty in identifying boundaries and bounded contexts:
Participants may have trouble drawing the boundaries between different bounded contexts or identifying the appropriate aggregates. Provide guidance on the principles of bounded context and aggregates, and facilitate discussions to help participants recognize the natural boundaries within the domain.
8. Inability to manage exceptions and alternative flows:
The event storming exercise may focus primarily on the “happy path” scenarios, neglecting the exceptional or alternative flows. Encourage participants to consider and capture the exceptional scenarios and alternative flows, either as separate subprocesses or as variations within the main flow.
Event Storming exercise is an iterative process, and it’s common to encounter some of these challenges. The key is to remain flexible, leverage the domain expertise of the participants, and continuously refine the model as the understanding of the domain evolves..The facilitator should emphasize that the visuals are just tools for facilitating conversations. The real value comes from the discussions and domain knowledge shared during the session. Focus on understanding, not just filling the board with sticky notes.
