How exactly do you develop software or elicit requirements when the team’s understanding of the domain in question has not yet been developed? After all, each software is supposed to solve the problems from a specific domain and support or enable the business processes.
According to Eric Evans, a domain can be defined as follows: “A sphere of knowledge, influence, or activity. The subject area to which the user applies a program is the domain of the software.”
It is therefore a delimited area of knowledge, influence or activity and results for example in from the corresponding company that is to use this software, its industry and problem area to be solved – e.g. a financial domain (e.g. for a banking or crypto software) or telecommunication domain (e.g. for a sales partner software). Of course, this can and usually will consist of additional sub-domains, depending on the complexity of the domain and software. However, the modeling of domains & co. is rather a part of the “Domain Driven Design” method.
The relevant subject matter experts usually have a deep knowledge of the domain by nature, but ultimately the implementers of the software must also understand the domain, such as, for example. The developers, designers or product owners. How will a team implement software without understanding the domain behind it? This team is ultimately responsible for solving the problems. Only with a deep understanding can the appropriate solutions be developed.
Event Storming is a practical method to create a basic understanding of the domain among the other team members as well and to understand the language or terms of this domain. Imagine you have to develop a software in the energy industry and you are bombarded with terms like market communication, network operator and EDIFACT. Without a basic understanding, it will hardly be possible to develop good solutions here. That’s why event storming involves interactive workshops with lots of sticky notes and the business and IT experts exploring the domain enough to build an interdisciplinary understanding to proceed with further system modeling and implementation.
As the name of the method implies, it is based on business events that occur during the business process under consideration. These events are described in the past tense, so they are events that have already happened.
In addition to the events that are written down in orange sticky notes according to convention, there are also the following sticky notes, among others:
- Blue sticky notes: commands (“Commands”) that lead to a certain event (e.g. “Send contract confirmation”, “Create account”, “Buy product”, …)
- Yellow sticky notes: Actors that trigger the command (e.g. end user, customer, …)
- Purple sticky notes: business processes that process a command with a specific business logic and that thereby generate one or more events (e.g. “process returns”, …)
- Pink sticky notes: external systems that can resolve a command (e.g. CRM system, CMS, …)
- Red sticky notes: questions, problems, risks or decisions
- More yellow sticky notes: So-called aggregates, which groups several sticky notes such as event, actor and command and gives them a name
There are other sticky notes that are a bit more technical. You can learn more about these options in the literature listed.
