Event Modeling – Extensions & transitions
Summary, what do we have after Event Modeling
We can easily imagine how the system will behave after implementation; everybody is on the same page,
We know that the implementation is feasible,
We know the estimates,
Now let's see where we can drive from Event Modeling.
UX & UI
The relationship with Customer Journey is straightforward. You can easily add more swimlanes: Steps, Actions, Needs & Pains, Touchpoints, Feelings, and opportunities. With this extension, you ensure that the usabilityis discussed with the Team and has a rightful impact. No need to repeat the story.
Planning & carving the delivery of the product
With 'Event Modeling', we can easily mark which part of the story we want to test and see how we can progress. It gives us ultra flexibility to shape the product. Preparing long roadmaps doesn't often work, but understanding how and in what steps to build your platform/system with the current best understanding, lets you be flexible and agile.
Take a look at the screenshot below. A User Story is just a sequence of frames/slices. Technically set of frames can be linked with a particular 'User story' defined in your backlog. You may see that something is deployed or in production, etc.
Insights
As a Product Manager, it's our job to understand what customer truly wants and needs. We often create small experiments to validate our hypothesis. With 'Event Modeling', it is effortless to asses relevant insights. Imagine you always know the number of events you have defined, group by release version/cohort.
Source code
There are many ways to translate specifications to code. With only .net there are a few frameworks worth checking: Eventuos, Marten. So let's see how things can be translated:
| Visual element | Corresponding class in source code |
|---|---|
| event, command, view | event, command, read-model |
| arrow pointing to event | command-handler & aggregate |
| arrow pointing to view | projection and read-model |
Tests
A lot of tests can be derived straight from the specification. What we have observed is, given certain Team's habits/standards, the number of tests is highly correlated with specification (for instance, the number of inputs for the view). The valuebehind well modeled specificationis that it clearly shows what to test and enriches them with meaning & context.
Gherkin
Modeled scenarios translate very well to automated acceptance tests written in Gherkin. All you need to do is cut the storyline. The part on the left becomes the 'Given'; we act on the cutting edge and expect the nearest part on the right.
Unit tests
Unit tests for projection and model can be easily derived from the specification. The number of input arrows to the view would most likely be the minimum number of UT for the projection.
Since an aggregate belongs to one swimlane, the number of unit tests for an aggregate would be, at minimum, the number of events in that swimlane.
CQRS & Event Sourcing
You've likely noticed that Event Modeling translates effortlessly to source code using CQRS and Event Sourcing. However, there are lots of myths about it. We'd recommend reading about from top sources: