Event Modeling and Event Sourcing with AI

Adam Dymitruk joined me for a practical session on Event Sourcing and Event Modeling. We had less time than expected for deep Java coding, but we still got a generated program running and validated the main workflow end to end.

Co-Speaker

Adam Dymitruk

Co-host at Adaptech Group

Adam coined the term Event Modeling and has been refining the methodology for over a decade. He started coding in 1983 and is the founder of eventmodeling.org. In this session he explained the core concepts and helped turn a sketched model into a running Java example.

WebsiteGitHubYouTube

Event Sourcing vs Event Modeling, in Plain Terms

The most useful part of the stream was separating two ideas that often get mixed together.

Event Sourcing is a storage strategy. You append facts as events, and build views by aggregating those events. You keep full history because you do not overwrite past events.

Event Modeling is a design method. You map user actions and system behavior as commands, events, views, and aggregates, with roles that interact with the system. Automation can be added later as the model grows.

In short, Event Sourcing answers how data is persisted, Event Modeling answers how behavior is designed.

Building the Event Model First

After the concept split, we sketched an initial event model on a Miro board. That part was simple and productive. It gave us a concrete shared picture of actors, commands, events, and views.

Adam repeated one key point during the stream: the board is not just a workshop artifact, it is also the living specification. I still think synchronization with source code needs discipline, but AI tools can already read these structures surprisingly well and use them as implementation input.

If you want to go deeper on tooling for this approach, Martin Dilger and the team at Nebulit have built dedicated Event Modeling tooling worth exploring.

The following board is a simplified snapshot of the model we sketched in the session.

From Model Screenshot to Running Demo

After creating the board, we took a screenshot and fed it into GitHub Copilot in Docker sbx. From that, we generated a first running example.

The generated app was more verbose than expected, mostly because the repository already contained context that framed the project as an Event Modeling demo. So the output included more explanation and structure than we wanted for a minimal sample, but it still ran.

We did not have enough time to fully dissect the Java code in the stream. If you want to inspect the implementation details, the session repository is public.

What I Take Away

Event Sourcing still looks like a very practical persistence strategy when history and traceability matter.

For Event Modeling, I am optimistic but still cautious. The method is strong for collaborative design, but large boards can become hard to navigate. The next step for me is simple, I need to apply it in another real project and see how it scales.

During the stream we also wanted to watch this short video by Adam, but ran into audio issues. Worth watching separately.

If you want to explore further, the Event Modeling resources page and the community Discord are good starting points. There is also an Event Modeling book in German if that is your preferred language.