Building Blocks of Event Modeling for Systems Engineers

TL;DR

Event modeling is a technique for documenting and developing complex software systems. It uses three core building blocks: Commands (actions), Events (facts), and Read Models (dynamic models generated from events). By visualizing system flow, identifying bounded contexts, and incorporating UI mock-ups and business rules, event modeling provides a clear and comprehensive view of system behavior.

Benefits include:

• Always up-to-date documentation
• Quick learning for new team members
• Shared understanding of system functionality
• Simplified project management
• Improved scalability and maintainability

Best practices:

• Use event sourcing and CQRS for implementation
• Treat each slice as a unit of work
• Continuously develop and refine the model
• Use event modeling for testing and reusability

Introduction to Event Modeling for Systems Engineers

Event modeling is perfect for systems engineers who want to document and develop complex software systems. As a systems engineer, you can use event modeling to make a clear, comprehensive, and timely visual representation of the upcoming software. The expected time and specific details can be calculated, perfect for meeting expectations without a lot of mistakes.

If this is your first time hearing about event modeling, this Blog might be better for you.

The Core Building Blocks of Event Modeling

• Commands (blue): Commands represent actions that cause changes in the system, essentially corresponding to API methods.
• Events (orange): Events are facts that occurred in the system as a result of commands, always formulated in the past tense.
• Read Models (green): Read Models are simple, dynamic models generated from events, providing data for UI or system automation.

Getting Started with Event Modeling

To use event modeling, first start by visualizing your software’s flow from left to right, representing the passage of time. Begin with an event, such as “Add Product” in an application. This command starts the business logic, which processes the action and, if successful, generates an event like “Product Added”. Following this, create a Read Model that represents the updated state, such as the cart’s contents and prices. This approach allows you to map out the entire system’s behavior, including all side effects and business rules.

Organizing Events and Identifying Bounded Contexts

As you develop your event model, organize events into lanes to create natural groupings, which can give an insight into bounded contexts from Domain-Driven Design. This organization helps in identifying functional slices of your business logic. Each slice typically includes a Command, Event, and one or more Read Models, forming manageable work packages.

Incorporating UI Mock-ups and Business Rules

Incorporate UI mock-ups (hand-drawn or from design tools like Figma) into your event model to provide visual context. This integration helps bridge the gap between the technical representation and the user experience. To document business rules, use Given-When-Then methods within the model. For example, you might add a rule stating that a maximum of three products can be added to the cart.

Benefits of Event Modeling for Systems Engineers

As a systems engineer, you’ll find that event modeling provides several benefits. It serves as an always up-to-date documentation of your system, facilitates quick learning for new team members, and creates a shared understanding of how the software (and the business) functions. The slices naturally form tasks or user stories, making project management more straightforward. Moreover, the model becomes the single source of truth for your application’s functionality and business rules.

Implementing Event Modeling with Event Sourcing and CQRS

When implementing a system based on your event model, consider using event sourcing and Command Query Responsibility Segregation (CQRS). These concepts align well with event modeling. Event sourcing involves storing the state of your application as a sequence of events, while CQRS separates the read and writes operations of your data model. This separation allows for optimized performance and scalability.

Best Practices for Working with Event Models

As you work with event models, you’ll notice that they naturally lend themselves to continuous development and flexible methods of development. Each slice can be treated as a single unit of work. This process helps with ever-changing configuration and delivery practices, as you can easily identify which parts of the system are affected by each change without having to fix the entire system.

Testing and Reusability with Event Modeling

Event modeling also provides a solid foundation for testing strategies. Each command and its resulting events form a clear unit that can be tested in isolation. You can easily create integration tests can verify that events are correctly processed. As you become more experienced with event modeling, you may find opportunities to identify and extract common patterns in your systems. These patterns can create the basis of reusable components or templates, speeding up the development of future projects and ensuring consistency across your applications.

Conclusion

Simply, event modeling offers systems engineers a straightforward yet powerful approach to document and develop complex software systems. By focusing on actions, business logic, and reactions, and incorporating the factor of time, event modeling provides a clear and comprehensive view of system behaviors. As a systems engineer, this approach can lead to more maintainable, scalable, and understandable software systems, while improving communication with non-technical stakeholders.

Additional Resources

You can read more about each step for a successful event modeling workshop on eventmodeling.org.