Event simulation cheat sheet

Event simulation cheat sheet

Download as PDF, View on Miro

The strength of event modeling is its simplicity. This cheat sheet briefly describes four building blocks that can be used in four different schemes.

When you’re running an event modeling session, it’s good to get people up to speed quickly. Use this table for your own understanding or take it to a workshop to help get started for those new to event modeling.

4 building blocks

In the left part of the cheat sheet, four possible building blocks are described:

Trigger: What “triggers” a usage scenario? This can be a user through the user interface or an external application calling our public API. Or it could even be a robot and also an automated process.

Describe it using a simple http endpoint scheme or route. Designers can also be involved to show a complete design, but the main focus should remain on the flow of information. So just using an empty white frame with the name of the UI element is enough to get started.

Team: Describes the intention to change the state of the system. Complete with appropriate parameters.

Event: Describes the business fact that changed the state of the system and was saved to disk This is the most important piece of understanding the system. Always find a name for it that explains what happened in the business context. Also put all the necessary information in it. The more realistic the data, the better.

Kind: Describes a request that reads, interprets, and processes previously generated data and provides it to a specific user interface. The request may also trigger the generation of a report or other automated process that works with the data.

For example, in the tabular world, this can be implemented with a simple read SQL query. In a complex scenario, this could be a read model that aggregates events and stores the result anywhere.

4 patterns

The right part of the cheat sheet shows four possible schemes and ways to connect the building blocks within these schemes.

Command pattern

Trigger -> Command -> Event(s)

This pattern defines the state change and its path from the beginning (what is the trigger?) to the end (what is the state change?). It starts with a white field (Trigger), followed by a blue field (Command) and then one or more yellow fields (Event). First, each cell should be given a name to give the usage scenario a sense in the context of the business. After that, go to a finer description and add the appropriate parameters or attributes to the blocks.

Pattern representation

Event -> Issue

This pattern combines existing board events with a green “View” square. This allows you to quickly get an idea of ​​what information will be used. On the other hand, this means that only the information that already exists can be interpreted and presented in the view. Therefore, you should quickly notice if something is missed or forgotten. Also, give the “view” a meaningful name. Business people will love that they understand better when you show how you plan to query the data.

Pattern of automation

Event -> View -> Automated Trigger -> Command -> Event(i)

This pattern is used in cases where the system must perform any actions automatically. If you look at the chain of the pattern, you can see that it is almost the same as the combined form of the Command and View pattern. With the robot in the center. You can describe the same thing by replacing only the robot-trigger with the user. At the same time, automation is lost, but the flow of information remains the same.

Event modeling does here a very useful thing for understanding good software architecture. Automation works just like the user. Some process observes some data through a view and triggers a business case if conditions are met. In this case, Adam teaches that the representation followed by the automated process is a simple to-do list. For each row, the automated process calls a use case that provides a new event. And this new event is then interpreted by the Todo-View, which will mark that row. That way, no row calls the use script twice. Thus, the complexity of the automated process does not exceed reading the to-do list and calling it. There is no business logic in it.

Translation pattern

Event (source system) -> View -> Automated Trigger -> Command -> Event(self) (other systems)

The chain of building blocks looks the same as in the case of the automation pattern. This is because they are the same thing. The only difference between this pattern is that the broadcast pattern is used to transfer knowledge from one system to another. If you need to notify another system that something has happened, use this pattern.

This pattern has limitations. On the read pattern side, you can only read events from one system. There are no restrictions on the recording side. A translator can publish knowledge from one system to several other systems through the Pub/Sub mechanism.


Each pattern modeled on the board can be used as a “fragment”. A fragment is the minimum possible work that can be handed over to a developer for implementation. This is because everything a developer needs to know is explained in this snippet. Starting from the top of the architecture and ending at the persistence level.

Related posts