Understanding Business Operations with Event Modeling

Rafael A. George Duval
3 min readApr 25, 2023

It should come as no surprise that software is eating the world, and IT is now a crucial capability in any Organization. Yet, most technical teams only have a shallow understanding of their domain. In my experience, they focus more on tech for tech’s sake than a business’s strategy and needs. Yet, most businesses have to catch up on these opportunities. I see more progressive companies with blended roles where technical people sit at the table.

Domain-driven design is both a way of thinking and a set of priorities to speed up software projects that deal with complicated domains. The team needs a problem domain model described by a vocabulary everyone agrees on. When you are close to the finish line, you can sprint if you have extra energy.

Promoting business concepts through the code base is essential to modeling a domain. Focus on something other than the technical platform — the business process of how things move throughout the system.

The bounded contexts are the most critical parts of domain-driven design. Bounded context has this concept of a core domain. With Domain-driven design, we explore different models until we arrive at the right one. Do not focus on the structural patterns at all. DDD models the ubiquitous language per bounded context. Bounded context exposes concepts from a single domain.

DDD brings domain experts and developers together. The goal is to develop software that reflects the mental model of the business experts. We, developers, are technical thinkers. Technical solutions come for us. It’s not that thinking is terrible. There are times when thinking in technical terms, less is better.

Defining Bounded Contexts communicates state change using Domain events. The stream of events represents the system’s state at any given time, thus the Core domain of the system.

The business core Domain is a part of the business Domain that is of primary importance to the organization’s success. The business core Domain is what makes the business unique. Each business sub-domain maps to a department. When we subscribe to a newspaper, we have a source of information. Then there are the consumers of that information, so we have natural patterns by doing event-driven.

An Event-storming session can lead to clarity of the business processes that the system needs to support. Since the timeline gets codified as part of a sequence of events, we end up with the single source of truth of what the system represents. From there, we can drive the structure of the system. People might be different. You might perform a given action with a given type of user. The other kind of user might do something different, like a corporate customer is distinct from an individual customer. Events are not a transport for data but a transport for meaning. What we are doing is communicating changes in a specific period. The communication mechanism we use at the business level will also be reflected in the code.

The simple form of an event storming session starts with defining a timeline with Domain events. They can be represented using the color orange. Use domain events to determine the business timeline. The events must be past tense and relevant only to a domain expert. The idea is to distill the core business domain rather than discuss potential solutions. The big-picture session invites as many people with business knowledge into a room to define an abstract business timeline. The session makes the timeline visible to everybody. People who know the industry will enforce a specific and accurate representation of the company. The session goal is to model an entire business timeline with events.

[¹]: Event Modeling

[²]: EventStorming

--

--

Rafael A. George Duval

✍🏼 Indie writer, chief editor of https://snippetsoftext.substack.com/ | 💻 Software Engineer | 📊 Tech Leadership