- Data driven design vs domain driven design software#
- Data driven design vs domain driven design code#
The slow speed of group learning is the primary constraint in the software development process. Yes, because you would already have learned what you needed to know to succeed. If you could do the project you just finished all over again, with the same team, knowing what you all know now, would you be able to complete it faster? The better the entire team understands the domain, the more likely the software implementation will reflect the domain, which is the primary purpose of DDD. Everyone, including nontechnical product owners, can participate in understanding and modeling the domain. That's a shame, because only the facilitator has to be a DDD practitioner to guide the group toward a complete model. While event storming is growing in the DDD community, it's almost unknown outside of that sub-specialty.
Data driven design vs domain driven design code#
The resulting model is then challenged with code in order to validate the group learning and verify the model. Finally, the relationships between bounded contexts are added to create a context map. Along the way, key test scenarios, users, and goals are identified and incorporated into the model. The group identifies aggregates that accept commands and accomplish events, and begins to group aggregates together into bounded contexts. Then the group adds the commands, or triggers, that cause the events, and considers all sources of commands, including users, external systems, and even time. The group starts with domain events, walking through the model forwards and backwards to ensure that everything is covered. Everyone participates, and the facilitator keeps the group focused and engaged, guiding progress toward a complete model of the domain. You run an event storming session as a facilitated workshop. Domain events capture those facts in a way that doesn't specify a particular implementation. The domain expert is not interested in databases, web sockets, or design patterns, but in the business domain of the things that have to happen. A domain event is anything that happens that is of interest to a domain expert.
To understand event storming you first need to understand two key terms. You can apply it to practically any technical or business domain, especially those that are large, complex, or both.Įvent storming catalyzes and accelerates group learning, often achieving in a few hours or days what more traditional modeling techniques never do-a common understanding of the domain in which the software must operate. The technique isn't limited to software development. The brainchild of Alberto Brandolini, it's a synthesis of facilitated group learning practices from Gamestorming and the principles of domain-driven design (DDD). Event storming is a rapid, lightweight, and underappreciated group modeling technique that is intense, fun, and useful for accelerating development teams.