When was your last breakthrough about software development? I
think I can resume mine in 4 steps:
1- Writing test is not optional to handle complex system
2- Good architecture is not optional to write test
3- Most programs are built with a CRUD approach, which isn’t easy to maintain
in complex systems
4- Event-driven architecture may help to avoid this CRUD approach, mainly
because Events can be domain concepts that we share with the business.
That’s why, coming from the DDD world I’m so interested in CQRS/ES and functional programming to handle complex systems. I’ve seen a few times already how the combination of DDD strategic patterns to handle contexts, CQRS/ES implementation and Event Storming for exploration of the problem space are efficient. It allows to get a very deep understanding of the problem, and a very robust way to implement the solution, all relying on the power of events.
Recently I’ve seen a few tweets about this “new” stuff: Event Modeling. And a few tweets later, I had the chance to organize an Event Modeling workshop in Lyon with Adam and Greg, that I had the pleasure to attend. Let me share some feedback here.
Event Modeling vs Event Storming
There is a very detailed post about what’s Event Modeling by the author Adam Dymitruk, thus I will rather give a short explanation assuming that you already know about Event Storming.
Both methods are starting in the same way: you want to “storm” events by asking business people to tell the story of their domain.
Then, you try to order the events in time to show that you can describe a business flow from start to end quite exhaustively.
From that point Event Storming (at least in the way I’m used to practice it) focus on the emergence of commands, aggregates and bounded contexts.
Event Modeling in the other hand will then focus on User Interface (UI). The goal is to add UIs to show the progression of a screen through the business flow. You will often duplicate the same screen, and just change some values to represent in which way the UIs are impacted by the events. Note that you can add different lanes to represent the UIs for different users impacted by the same events.
At the same time, some lanes can be added for the events. Some events are about inventory. Some are about payment… Yes, it’s just another way to let your bounded contexts emerge. And a very powerful one I think, because it makes clear that UI most of the time gathered data from many contexts.
Event Modeling keeps Events order
Practicing Event Modeling removes some Event Storming frustration for me.
I have facilitated many Events Storming in many organisations since 3 years now, and I often have the same feedback that losing the temporal relationship of events (when going from Event Streams to Aggregate) is a shame, because we loose meaningful information. I usually agree but answered that this relationship wasn’t “lost”, and that we could always take pictures to keep it somewhere.
Event Modeling just keep this relationship by default, and I think it’s a good idea in the end, because time matters when speaking about events (actually they’re just two sides of the same coin).
Event Modeling also focus on UI
I also observed during my Event Storming session that adding some UI sketch might help a lot to remove ambiguity.
One of the steps in Event Modeling is actually to draw all meaningful UIs for different users. It makes sense because it helps business people to have a better understanding of the “link” between domain events and the software they will use in the end. I think it helps them to translate from problem space to solution space if you will. Also, as already explain, it shows that UIs most of the time gather data from several contexts.
A different view of bounded contexts
The step of drawing contexts around aggregates like in Event Storming doesn’t exist. Instead the contexts emerge in even a better way I think: by putting events stream in different lanes depending on the things they are doing for the business.
Is it more about payment? Or inventory? Or security? We easily feel that all events do not lie in the same streams. And each stream of events might in the end represent a different bounded context.
A CQRS cycle keeping track of time
Last but not least: Event Modeling results in a “true” representation of a CQRS/ES system. We know the classical circular view in a CQRS system: View -> Command -> Event -> Model.
What does this circular system look like in time? Waves of View -> Command -> Event -> Model -> View -> Command -> Event -> Model … and so on.
In the end, using this Event Model as a blueprint for the software we are building makes sense, because it doesn’t miss any component that matters for business. We have the domain events and we have the UIs, and all the transition leading from one UI to another following the pattern View -> Command -> Event -> Model .
Finally, a silver bullet ?
I’m not an expert of Event Modeling, and like anything new I probably miss some disadvantages of this method due to my feeling that it removes many problems I met in my current way of working.
But I’ll try to use it very soon, because I see lots of potential in this approach.
I can see how it helps me to be closer to the solution space, with still something making sense for the business.
Something I already feel harder though might be to know how to represent aggregates with it. Actually this is probably due to the author view: he doesn’t really care about context or aggregate; but rather about streams. An event stream is a “logical” stream of events… Ie either a context or an aggregate depending on the context I guess^^
Anyway, I will try it and let you know how things are going 😊