I consider Learning Event Sourcing and Event Modeling some of the most crucial skills you can aquire as a Software Developer in 2025.
Itās no longer about Frameworks and Technology. AI will take over more and more of that. The crucial skill will be to be able to discuss and analyze Systems in a way both Business Experts and AI can understand.
I write weekly about exactly that in my Newsletter.
(This was Issue #13 of the weekly āEvent Modeling & Event Sourcingā Newsletter)
Should you model external Systems?
The topic came up recently in the community discord.
The answer to this question depends on the context. Typically, when dealing with external systems, the Dev Team treats them as black boxes. You make an API call, and you expect a response. The implementation details of the external system donāt matter.
So should we model them at all?
Consider a system that translates book titles via an API call to an AI service like DeepLink. Hereās how this is typically modeled. (Hint: people are confused by this)
You have a list of titles to translate (indicated by the green sticky) and an automation that takes care of it. In the end the title is saved in the system, indicated by the āTitle savedā Event.
Before moving on - look at the picture. Are you confused by anything?
Why is the command called āSave Titleā and not āRequest Titleā? Isnāt the command the API call?
If you paid close attention, thatās what youāve most probably been asking yourself a few seconds ago.
No, the command is not the API call. The API call is handled by the processor, and the command in our system simply stores the result of that call.
The confusion arises because we left out a part of the process.
Where does the API call happen?
Weāre not concerned with the specific implementation details. What matters is that we know weāll request the translation, and the DeepLink will return the result.
Itās about the information flow, not the implementation.
But then this is the question that comes up in your mind.
āIām trying to map this to the implementation, and Iām confusedā
Whatās the distinction here?
From the perspective of our system, there is no āTranslate Titleā, āTitle Translatedā, or even a āTranslated Titlesā read model. The goal is simply to visualize the flow of information. Avoid the temptation to directly map this to the code that needs to be written.
Make it visible
But at some point you need to make the mapping to the implementation, donāt you?
How do you know which slices belong to our system and need to be implemented and which slices are just showcasing information flow?
Make it visible.
In my models Slices are typically surrounded by a black border. Slices that just mimic information flow arenāt. Very easy to see.
Hope that made sense. This chapter was also added to the āLittleā Event Modeling book.
By the way, on Wednesday this week we had a pretty good Webinar showcasing the whole process from requirements to generated production code in about 120 minutes.
There is a recording available soon. If you want to get early access to it, just answer āRecordingā to this E-Mail. I might publish it for newsletter subscribers later today.
Want to work with me?
Iām looking for Teams that want to try Event Modeling in a safe environment. I want to work with them for one day on a concrete domain problem in a workshop.
The goal is to find out, how your Team will benefit from the structured communication Event Modeling provides.
If you are a developer and you want to improve your skills in Event Modeling & Event Sourcing - start with my Book āUnderstanding Event Sourcingā
Want to practice your skills in a safe environment?
The Online Course āImplementing Eventsourcingā gives you exactly that. Itās a perfect companion to the Book!
Everything I know about Evenet Modeling & Event Sourcing in one course.
Martin Dilger
Join the Agentic Engineer Program
Apply Spec-Driven Development Hands-On - Event Modeling, Event Sourcing, and AI Engineering with autonomous agents.
Book a Call Today
Want to talk through how Event Modeling could work for your team or project? Letās have a quick, no-pressure conversation.