Resolving Disagreement and Friction with Event Storming

During an Event-Storming session, it is common for disagreements to arise, which can state areas of friction. This friction can often be caused by ambiguity in naming conventions or conflicting concepts. Recognizing that team members may have different ideas and perceptions of the same problem is essential. Two key terms must be understood to understand event storming: a domain event and a domain expert. Yet, domain events represent facts about the domain, which only change when the underlying business changes. Domain experts know the business itself. After all, software developers know about software, not about specific business domains.

Event Storming is not limited to software development. You can apply it to any technical or business domain, especially large, complex, or both. Think about the last project you completed. What did the developers have to do to understand the domain model and build the system? While this process may lead to a common understanding of the entire domain by all team members, it’s unlikely. Instead, these conversations can occur during an event storming session. If you start from behavioral modeling, you’ll get distracted as you break down behaviors into tasks and link them into processes. Those are implementation concepts, not business-domain concepts. Usually, these conversations happen, but they all occur with event storming. This way, you can sort out any conflicts or discontinuities in any part of the domain while everyone involved is present and engaged. If the developers need to understand the domain, they can model it.

[¹]: EventStorming