Initial thoughts post the event modeling workshop

I attended the first ever event modeling conference in Munich this week, hosted by Martin Dilger. You can find out more about the event here:https://www.linkedin.com/feed/update/urn:li:activity:7382309099826221056/

I got into event modeling because I was looking into the various tools available for visualizing requirements that’s understandable by both business and development. I had been looking at Event Storming for a while but when I found out about Event Modeling, somehow I found it much easier to transition the work done from the visualization exercise to implementation. It works especially well if you’re already used to working in vertical slices.

Since it was a small group, there was a high level of interaction which resulted in quite a number of a-ha moments for me.

1. Slices on the event model are not necessarily slices in implementation The main purpose of the event model is to communicate information flow.

In an event model, everything is either a state view, a state change triggered by a UI, a state change triggered by an automated processor, a state change triggered by an external event. I had the understanding then that each of those visualized slices could therefore straight up be translated to a slice in the code. Turns out this is not always the case. One of the examples we discussed was processing business rules. The example that we discussed was validation of a shipping manifest. You have this big load of input and you have a set of policies that dictate things like blacklisting senders, or perhaps restrict what kinds of items could be shipped and so on. The event model can then look like a chain of several automation slices that each look at the policy in question. However, when implemented, this could all fall under one vertical slice. Another example was if you had for example a wizard in the UI where you walk the user through a series of input forms, you could still visualize this in the event model as a series of state view and state change slices even though you haven’t posted the data to the server for persistence just yet. You can consider the UI to be a swimlane because technically, there is some form of persistence being done on the UI layer.

2. Expiration doesn’t have to be modelled as an event, it could be a static read model consumed by a daily processor that triggers commands.

I’d always thought that when something expired or something is due you fire an event when it happens, but it’s actually easier to pre-calculate it into a read model or state view slice.

3. Dynamic Consistency Boundary and the death of aggregates.

I had heard a lot of discussions about this but i pretty much glazed over them because I thought it would be too complicated to understand. Also, it meant the death of my beloved Aggregate. One of the community voted topics was the DCB and that made me understand the concept a little bit more. The idea is that by enabling tagging on certain events, you can create a slice that reads only the events needs to make a decision instead of reading in the entire history of events. I guess I struggle with the bit where if you don’t have the event model, it’s difficult to figure out what your system does. Whereas if you have a domain aggregate, that would be your source of truth on what changes the model i capable of doing, everything would be contained in the aggregate.

I can’t help but think though that this is a little bit like the blind men figuring out what an elephant was though. As if you were building an event sourced system, swim lanes would essentially serve as the aggregate, and ergo a package, and every slice is the api to that package/aggregate, so you essentially have that interface right there.

I know I had a few more but i will need some time to digest and process my thoughts. I’m still quite tired after the trip, it was exhausting, but very much well worth it.