How long do event modeling sessions last?
The basics
Event Modeling was designed with Event Sourcing in mind. Event Modeling is a modeling/design tool. Event Sourcing is an application design pattern. This document won’t go into the details of Event Sourcing but you should know that in Event Sourcing the event is recorded as the primary artifact. Event Modeling is focused on these events. If you are not using Event Sourcing, the events still occur but are not recorded to a database. Your model should still show the event.
An Event Model tells a story. It has a beginning, a middle and an end. Time flows from right to left on the model, therefore the story begins on the right and moves through stages to the left of the model.
(insert image here to show Time on model)
Use of CQRS
The Event Sourcing application pattern will always use the CQRS (Command Query Responsibility Segregation) pattern. The CQRS pattern is optional when Event Sourcing is not used. Event Modeling leans heavily on the assumption that CQRS will be used.
Because of the close relationship between Event Modeling, Event Sourcing, and CQRS there may be rules that feel awkward if you use a different architecture for your application.
The vocabulary
Common concepts used in Event Modeling:
- Time
- Project
- Journey
- Slice
- Workflow engine process
- Command
- Request
- Event
- View
- Must
- Should
- Always
- Never
Time
Processes begin on the right side of the model and time flows from right to left within each slice of work.
Individual slices can run async and don’t require the preceding slice to complete first unless there is a distinct dependency on a previous slice.
A slice that has a dependency on another slice must be drawn to left of the dependency, showing that the dependency occurs first.
All arrows and lines on the model must flow from right to left. (because “time” is a one way street).
Project
The project is the top-level object represented by an event model. It can represent an entire application, a portion of an application, or the interserction of several applications.
Journey
A journey contains one or more slices of work and represents a set of steps to complete a multi-step process.
Slice
A slice is synonymous with a user story. It represents a single change to the system triggered by UI, an API, a cron-job, or some other process. It finishes by accomplishing a single task and updating information within the system.
Workflow engine process
An process that reacts to some event, and triggers another event. In event-driven software the Workflow Engine processes allow you to execute a multi-step Journey by executing a single event, which triggers another event, and continues until the entire journey is completed.
Request
A request expresses the intention to query and return data. It should never cause a change within the system.
Command
A command expresses an intention to perform some action or change within the system. When something has been changed, then an event has occurred. Commands and Events have a 1 to 1 relationship. *Commands never return data.
* Critical CQRS Principle: With the exception of returning an ID generated by an Insert command, a command must not return data. Requests must return data without causing any changes to the system. Commands and requests work separately to perform discrete jobs. They are an example of the Single Responsibility Principle. This is a core rule within CQRS. If you were to allow commands to return data, or requests to change the system, you would introduce side-effects that will make the system exponentially more difficult to maintain. This rule is critical in the software we build and any code that breaks this rule must fail in a code review.
Event
An event is the result of a command. It represents a fact of something that has occurred in the past. Once the event has been created it is immutable. You can not change the past (or an event). You can not delete the past (or an event). If you wish to negate an event, then you must perform compensating actions to reverse the effects, similar to fixing a mistake in accounting, you can add a new event that offsets the effect of a previous event yet still leaves a record of all the events.
View (aka Projection)
A view or projection is data that is available to the requests.
It is common to store events and views in separate databases. Events are typically used by the commands and views are used by the requests.
How to create an Event Model
Tools
There are no required tools or software needed to create an event model. Originally event models were created using sticky notes or index cards. There is nothing wrong with that approach and it works well, but the drawback is it can be difficult to get all the participants into a single location and it can be difficult to preserve the artifacts from the Event Modeling session.
There are many online collaboration tools that can be used and they don’t need to be Event Model specific. I have used the following with varying degrees of success:
- Draw.io
- Miro
- (What is the one we used at work that like Draw.io)
- OneNote
- pen and paper
I use Draw.io the most because it is free, which means that I can work and collaborate with others without worrying about whether they have a licence, and I have a certain degree of confidence I won’t lose my models in the future due to the company closing or making their licensing impractical.
Draw.io certainly has drawbacks and I find it tedious to select and edit items but it works well and I have used it for several years now with Event Modeling.
Who should create the Event Models?
Event models exist on a spectrum of technicality. They can be very simple with slices defined by business users, but are improved by details understood by developers. You must have:
- someone that understands the desired business process and business rules
- and someone that has learned the rules of event modeling
- and someone with a good understanding the basic principles of CQRS and your architecture.
With all that said, an event model can easily be created by a single person that possesses that knowledge or by a group of people that bring parts of that knowledge together.
As an engineer, I typically work with a Product Manager (business specialist) to develop our event models. The rest of the dev team joins in at times to observe or contribute ideas. The Product Owner (above the Product Manager) may be involved but in our case is usually an observer and corrects or explains any business processes that were not clearly understood by the Product Manager.
Feel free to substitute participants in order to get a good mix of business and technical knowledge into your modeling sessions.
How long do event modeling sessions last?
I like one to two hours per session, but there is no hard rule. Do what works best for you and your collaborators. You will likely be able to start coding after your first session, but expect to have many sessions in order to complete an event model. It is an iterative process and we typically have many sessions to define a preliminary model at the beginning of a project. Then we meet regularly during the development of the protect in order to refine and expand on the event model as new scenarios and requirements are exposed.
When is the model complete?
In my experience it is best to try to keep the model in sync with the application forever. If you expand or improve your application, your event model should continue to evolve. So I never consider an event model complete unless the project dies.
EventModel.io 
Leave a comment