Business Process Modeling: Events, Producers, and Consumers

Hello! Welcome to the first lesson of your course on designing real-world, high-load distributed systems.

Given your extensive background in building and managing complex systems at Yandex and Raiffeisen, we will bypass introductory concepts and focus directly on the practical patterns and technologies you've expressed interest in.

This first module is dedicated to Event-Driven Architecture (EDA). Today's lesson lays the groundwork by focusing on a crucial, often-overlooked step: modeling the business process itself.

Lesson 1: Modeling a Business Process with Events

Learning Outcome: By the end of this lesson, you will be able to model a business process by defining its event sequences, producers, and consumers.

This is the essential "problem space" activity that must precede the "solution space" of architectural design. A well-defined event model is the blueprint for building robust and scalable event-driven systems, and it's a foundational practice for architectural styles like Event Sourcing and Domain-Driven Design (DDD).

1. From Activity-Centric to Event-Centric Models

Traditionally, business processes are often documented using notations like BPMN (Business Process Model and Notation). These diagrams excel at showing a sequence of activities and responsibilities.

Take a look at the following BPMN diagram for an employee termination process:

While detailed, these diagrams can become complex and difficult for all stakeholders to agree upon. The focus is on the how (the tasks) rather than the what (the significant business moments). An alternative approach is to model the process around the events that occur in the business domain.

To understand the motivation behind this shift, please read the introductory sections of the following paper.

The key takeaway is that focusing on a sequence of activities can obscure the core business logic and lead to misinterpretation. By focusing on discrete, unambiguous business events, we can create a model that is both precise for developers and clear for non-technical experts.

2. The Event-Driven Business Process Modeling (EDBPM) Method

The EDBPM approach provides a structured way to create this event-centric model. It involves identifying the key resources, the events that change their state, and the systems that react to those events.

Let's dive into the mechanics of this method.

Let's break down the components of the model presented in Table 1:

• Economic Resource: The central entity being tracked, in this case, "labor" (the employee).
• Process: A logical grouping of events that represents a business workflow, like Joiner Process or Leaver Process.
• Event: A significant, factual occurrence in the real world that affects the economic resource. For example, Contract signed or End date. This column defines the event sequence.
• Responding Systems/Units: The columns representing HR System, User account management, etc. These are the actors in our system.

In the context of Event-Driven Architecture, these actors map directly to two key roles, which are defined well in the Microsoft Azure Architecture Center.

Based on these definitions:

• Event Producer: The component that generates an event. In the EDBPM table, the system that first registers the external event and notifies others is the primary producer. For the Contract signed event, the HR System produces the event for other systems to consume.
• Event Consumer: A component that listens for and reacts to an event. In the table, any system with a defined response to an event is a consumer. For Contract signed, the User account management and ITSM tool are consumers.

Practical Exercise

Let's apply this. Using the BPMN diagram for "Termination of Employment" we saw earlier, how would you start to model that process in the EDBPM table format?

1. What is the economic resource?
2. What are the key external events you can identify? (e.g., Resignation submitted, Equipment returned, Final payroll processed).
3. Who are the producers and consumers for these events? (e.g., HR, IT System Access, Financial Reconciliation).

Try sketching out a table similar to Table 1 for the termination process. This exercise of translating from an activity-flow model to an event-list model is a fundamental skill in designing event-driven systems.

3. Refining the Model and Connecting to Architecture

A first draft of the model is a great start, but it needs to be validated for completeness and evolved to meet future business needs. The EDBPM paper offers guidance on this.

This evolution from an "as-is" to a "to-be" model is where business modeling directly informs system architecture. The responses marked for automation (* in Table 2) become the functional requirements for your services. For example, the response *create a UserID for the Contract signed event implies a service that consumes this event and calls an identity management API.

This model now serves as a blueprint for making architectural decisions. The interactions described in the table can be implemented using different architectural topologies.

• Broker Topology (Choreography): Systems publish events to a central channel, and other systems independently subscribe and react. This aligns well with the EDBPM table structure, where each system has its own defined response to an event. It promotes high decoupling.
• Mediator Topology (Orchestration): A central component (the mediator or orchestrator) manages the workflow, sending commands to other services. In the EDBPM example, the ITSM tool acts as a mediator when it run[s] onboarding workflow, coordinating multiple steps.

Your experience with Sagas in payment systems likely involved making these very trade-offs between choreography and orchestration. The EDBPM model gives you a clear, business-grounded framework to guide that decision.

Conclusion

In this lesson, we established a formal method for modeling business processes in a way that directly supports event-driven architecture.

Key Takeaways:

• Modeling a business process around external events rather than internal activities creates a clearer, more robust foundation for system design.
• The Event-Driven Business Process Model (EDBPM) provides a simple table-based format to define event sequences, identify producers, and specify the responses of consumers.
• This model serves as a crucial bridge between the business domain ("problem space") and system architecture ("solution space"), informing decisions on automation and architectural patterns like choreography vs. orchestration.

Preview of the Next Lesson:

Now that we have a method for defining an event stream, our next lesson, "Implement a projection to create a read model from an event stream," will take the next logical step. We will explore how to consume these events to build and maintain optimized query models, a core technique in both CQRS and Event Sourcing architectures.