Although it is very effective, DDD is often overlooked by developers and we believe that Event Storming is a great way to introduce DDD without even naming it!

Event Storming & Domain Driven Design

Event Storming is a collaborative exploration and modelling of complex business domains workshop. Event storming involves gathering all stakeholders of a project to align on a technology-neutral understanding of the business domain and the problem at hand. This grounds the solution in the appropriate business context, helping to ensure that the business domain experts and technology experts arrive at a common understanding before constructing a system. It is a highly collaborative process, and can often surface quite a bit of knowledge that would otherwise be siloed away within individuals and teams. Also, it is an excellent way of getting the big picture of the product environment, its needs and goals, and to assess its complexity. Event storming supports group learning and is a fun way to integrate development and product teams. It helps if teams want to create alternative solutions together by visualizing and selecting them. Event storming may also be useful for teams with mature products to order the process and find out about bottlenecks and areas of conflict. It is also a great chance to learn about dependencies in the entire domain that might be less visible on a daily basis, but can significantly affect decisions made about the product, both on the technical and business ends.

It is extremely important to provide unlimited modeling space, tons of stickies in several colors, markers, some masking tape and finally, a relaxed atmosphere. Using a big wall and post-its, a team can draft a software system design in a few hours. Actually, Event Storming allows to introduce the patterns in a less abstract way and dive deep into the Domain Driven Design world. Event storming and DDD allow us to model a system in an asynchronous way, which is suitable for reactive, cloud-native systems analysis and design.

Getting started is easy: stakeholders simply begin to think of and write down interesting business events on stickies and affix them to a modeling surface. Then, it is time to create flows: a flow of events is simply events in order from left to right, the order representing time. Events may have their roots in commands, but they might also be triggered by people, time, documents, or external or cascading events. Then, normally the events and commands are grouped around aggregates. Each aggregate represented a specific business concept that had a local responsibility. And then, it’s time to discuss the ubiquitous language. All people involved in the product development should speak the language of the domain to support a shared understanding. Bounded context is the setting in which a term appears, determining its meaning. Each context has a clear boundary and is consistent, having it own rules but still communicates with others.

An event storming workshop is a very dynamic experience. It may begin with a very simple flow of events. But shortly after a few events emerge on a workspace, a more detailed discussion is bound to emerge. Unlike more formal modeling techniques, such as UML, communication and discussion are the most critical outcomes that emerge from this exercise.

That doesn’t mean that teams can’t keep the output of the workshop in the form of diagrams or other artifacts, however event storming is all about the free flowing of communications.

The goal of event storming and domain-driven design (DDD) is to establish a technology-independent language and detailed understanding of the business needs and processes. This will allow the business domain experts – those most familiar with the stock trading domain and the role business has in it – to communicate their domain knowledge with the rest of the team. Stakeholders involved in a modeling workshop may include technology experts, project management, user experience specialists, quality assurance analysts, and anyone else involved in the execution of this project; however, the most important people to include are the business domain experts.

Eric Evans, thought leader in software design, domain driven design and domain modeling, states: “The heart of software is its ability to solve domain-related problems for its user.”
This means when developing software developers should not primarily focus on technology, but rather on the business side, therefore the functional area which we would like to support: the domain.

DDD distinguishes between three types of domains:

1. Core Domain
What makes the platform special, the small portion of the expertise and software that gives an edge on the market.

2.Generic Subdomains
The ones which are necessary for the platform to survive, but which are not intrinsically a competitive factor.

3. Supporting Subdomains
Something which is not enough general purpose to be available off-the shelf, and needs to be developed in a custom way.

Understanding whether you are in the core or not is vital, it helps you make important decisions regarding investment and development effort.

In the core domain it is extremely beneficial to work with few internal developers that have a long-term understanding of the problem as well as easy access to key domain experts in order to foster a successful collaboration: more quality generates more revenues.

Besides, quality above a given level won’t turn into more revenues in supporting subdomains, which are usually cost-driven. If you are in the generic subdomain it is recommended to use an existing software solution as it won’t be much of a differentiator.

Learning about these different areas and their distinction may increase awareness
regarding what to focus on and what questions to ask in the future. Also it helps to know whether the respective software development project is a game changer or if it may just playing a supporting role. Although everything is important to the business, not everything is equally important. DDD allows teams to constantly learn about the business, and translate findings into working software, which delivers true business value.

The following EventStorming workshop formats are distinguished and often used within the field of DDD:

• Big Picture EventStorming
  Allows collaborative exploration of an entire business flow, looking for diverging perspectives and interests of the several stakeholders involved.
• Process Modelling EventStorming
  Focuses on collaboratively designing effective processes, leveraging a non-specialistic notation, in order to allow interdisciplinary collaboration of business, technical and UX-CX stakeholders.
• Software Design EventStorming
  Adds a level of depth on the previous format by exploring the moving parts of a software implementation of the solution and progressively injecting a more rigorous grammar.

Big Picture EventStorming normally involves around 10-15 but sometimes up to 30 people, who collaboratively explore everything that happens within a line of business by creating a timeline of events out of sticky notes on an “infinite” modeling area. The Big Picture EventStorming helps to identify Bounded Contexts together with the dev team: units of homogenous language and model consistency, which together form a heterogeneous whole. Within a bounded context, we define a Ubiquitous Language, where every term has exactly one, and only one, meaning. By designing a system out of bounded contexts, the problem can be solved at a time, without making the life harder than necessary by having to implement expensive compromises and trade-off solutions. It is a good strategy to detect the core domain, and identify “bottleneck” candidates, whose improvement might significantly benefit the whole system.

The result of a Big Picture EventStorming workshop is a large map of the group’s understanding of the business at the time of the modeling, never a final result. It can only be interpreted as a snapshot of the participants’ knowledge, and therefore serves as a starting point for further exploration, rather than a goal in and of itself.

Based on the Big Picture, participants move on to the Process Modelling and Software Design parts.

Team will work through the modeling process to first establish a technology agnostic understanding of the stock trading business domain, using business experts as the source of that knowledge. Then team translates those domain concepts directly into domain logic in their code, using the appropriate domain language. This will enable technology experts and business experts to stay closely aligned throughout the entire design.

It is about modeling the event and command flow, assigning commands and events into various subdomains that can be implemented by different teams and establishing the interfaces between subdomains.

Domain-driven design gives us the blueprints to transform the output of an event storming session into models that are formal enough to use for architecting and building a real-world system.

In a conclusion, I would like to highlight key advantages of Event Storming:

Fast
The event storming approach reduces the time it takes to create a comprehensive business domain model. What used to take weeks can be accomplished in hours during a single workshop.

Straightforward
Rather than using complex UML, event storming breaks the process down into simple terms that both technical and non-technical stakeholders can understand.

Engaging
One of the goals of event storming is to make modeling fun. It is a hands-on approach to domain modeling that invites each person to participate and interact. Besides being more enjoyable, event storming also results in more valuable insights as participants more readily engage in the process and offer their suggestions and expertise.

Effective
Event storming is not data modeling. Instead, it results in a fully behavioral model that can be quickly implemented and validated.

Perhaps the greatest value of event storming is in the conversations it generates. Teams can use the knowledge gained in the workshop to inform future modeling processes and build software from them, or can simply use event storming to better understand business processes and make better decisions going forward.

If you are interested in knowing more about Event Storming, I recommend you to read these two books:

• Introducing EventStorming book by Alberto Brandolini
• Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans

If you are interested in Event Storming, I highly recommend you to do Event Storming course in Apium Academy.