Event modeling: A socio-technical approach to system design

The approach balances intentional architecture with emergent design by modeling state changes through the journey of a product or system.

Core concepts

At its core, event modeling is about capturing and mapping out the key events that occur within a process or domain. However, the approach puts a strong emphasis on outcomes and value creation. It should help answer the questions of “why are we doing this?” and “what is the end result we want?”. Focusing on outcomes helps align the modeling process with real business and customer value.

As Dr. Russell Ackoff famously stated, “A system is more than the sum of its parts, it’s a product of their interactions”. Event modeling focuses on these interactions, shifting our attention from solutions to business outcomes. Some interactions create value, while others merely pass information through. Pass-through interactions can indicate inefficiencies, suggesting that data is in the wrong place and needs to move closer to where interactions can add value. Event modeling takes a socio-technical approach to design by focusing on the interactions between humans and technology over time in the form of events.

Dymitruk describes the approach as “modeling, over time, a system’s state changes caused by events.” Event modeling is a visual representation of interactions between systems and the resulting system state changes required to deliver a measurable outcome.

Key principles

Event modeling is guided by several core principles and concepts. First and foremost is the outcome focus, which ensures that all events and processes are tied back to desired business outcomes and value creation. Context mapping is another important principle, grouping events into contexts to create clear boundaries and promote loose coupling between different parts of the system.

The use of ubiquitous language is emphasised, ensuring consistent terminology across the model that aligns with business language, helping to create a shared understanding. Developing a ubiquitous language improves communication between technical and non-technical stakeholders, reducing confusion and rework. Event modeling prioritises scenarios over implementation details like user interface design, focusing on business logic and rules rather than premature solution design.

The concept of slices is central to event modeling, breaking the model into implementable pieces that deliver incremental value. Finally, event modeling leverages common patterns like commands, events and queries to structure the model, providing a consistent framework for implementation.

The event modeling process

Setting goals

The process begins by defining clear goals and outcomes. For example, a supermarket might have a high-level goal of improving customer loyalty. This could translate into an Objective and Key Result (OKR) of improving the home delivery service. Key results might include increasing the number of repeat orders from the same customer.

Identifying context

The next step is to identify the context in which the modeling will take place. This involves looking at the business activities that should be involved in achieving the mission. For our supermarket example, we might focus on the context of external orders for home delivery.

Mapping events

Once the context is established, we start modeling the interactions required to reach the key results. We identify all the different activities needed for home delivery and map them out as a series of events along a timeline. It's important to keep identifying who owns the responsibility for each outcome as this can reveal potential inefficiencies in the process.

Implementing the timeline

To implement the modelled timeline, event modeling introduces three key patterns:

The Interface Pattern: The Interface Pattern starts with the events from the timeline, including the facts. It’s an iterative process to include and update facts. The interface pattern represents the input coming from a screen, API or other source that results in an action (command) which allows us to apply an event. When not all input is directly available, the pattern can be extended with queries that provide the missing details.

The To-Do or Automation Pattern: The Automation Pattern, also known as the ‘To-Do Pattern’, is a state machine that listens to events it’s interested in. It subscribes to a starting event (or multiple events), creates an initial state and then updates its state based on subsequent events. When it reaches a complete state according to its business rules, it calls a command and then may subscribe to a resulting end event of that command.

The View Pattern: The View Pattern subscribes to one or more events from one or more process steps to deliver a read model. The read model can then be accessed through a UI or API. This pattern aligns closely with the concept of projections in Command Query Responsibility Segregation (CQRS).

The following shows how the three patterns connect with each other:

Benefits of event modeling

Event modeling offers several key benefits. It improves business alignment by expressing the model in business terms, enhancing communication between technical and non-technical stakeholders. The approach is flexible and technology-agnostic, allowing the model to evolve independently of implementation details.

Mapping events and their relationships helps identify gaps and dependencies, leading to more complete system designs. Each slice of functionality is discrete and testable, improving overall system quality. The event-driven nature of the approach enables systems to scale with high throughput.

Implementing event-driven systems

When implementing systems based on event models, several key considerations come into play. Event sourcing, which involves storing all state changes as an immutable log of events, is often used. Capturing all state changes as events in an event log provides a complete audit trail. The event log also allows for ‘time travel’, enabling the reconstruction of past states of the system for analysis, compliance or debugging purposes.

Command Query Responsibility Segregation (CQRS) is frequently employed to separate read and write models, improving scalability and flexibility.

Bounded contexts are implemented as separate services with clear interfaces, promoting modularity. Event-driven messaging, using message buses or streams, is used to propagate events throughout the system.

Challenges and considerations

While event modeling offers many benefits, it’s important to be aware of potential challenges. There’s often a learning curve associated with adopting event modeling, especially for teams used to thinking in terms of data models or user interfaces. It requires a shift in thinking towards events and state changes.

Dealing with eventual consistency in read models can be challenging for developers accustomed to synchronous systems. It requires careful consideration of how to handle scenarios where data may not be immediately up-to-date.

As systems evolve, handling changes to event schemas over time becomes important. Techniques like event upcasting may be used to translate old event formats to new schemas, ensuring backward compatibility.

While individual patterns in event modeling are simple, managing many fine-grained events and processes can introduce complexity. Proper tooling and practices are essential to keep this complexity manageable as systems grow.

Event modeling offers a powerful approach for designing systems around business value and outcomes. By focusing on the key events in a process, it creates alignment between stakeholders and supports building flexible, scalable architectures. While it requires new skills, event modeling can dramatically improve communication and accelerate the development of complex systems.