Iâve written about DevWorld 2026 already, but I never published my photos from the year before. So hereâs a throwback. DevWorld Conference 2025 ran on 27 and 28 February 2025 at RAI Amsterdam, and these photos are from the first day.
The way in: âWelcome to DevWorldâ, with a QR code to download the conference app.
The main hall
Inside, the main stage was in a large dark hall, with big screens on both sides of the stage and more screens hanging above the seats.
The main stage, early in the afternoon.
Duck Stage: âModeling side effects as Effectsâ
Most of my photos are from one session on Duck Stage 1. Itâs an open stage under the glass roof of the hall. The audience wore wireless headphones, a setup that lets several stages run side by side in one space without the sound overlapping.
The talk was âModeling side effects as Effectsâ, and the code on the slides was F#. The idea was simple: describe a side effect as data, then run it somewhere else. The first slide I photographed declared type Effect = SendEmail of string and a perform function of type Effect -> Async<Result<Cmd list, Error>>. Inside perform, the comments said where the real work happens: âcall to the email serverâ and âuse try/catch, process errorsâŚâ.
âModeling side effects as Effectsâ on Duck Stage 1: the effect is a type, and perform is the only place that touches the email server.
The next slide put Event Sourcing and Transaction Script side by side, using the same object definition for both:
decide: State -> Cmd -> Result<Event list * Effect list, Error>evolve: State -> Event -> Stateperform: Effect -> Async<Result<Cmd list, Error>>init: State * Effect list
The two handle functions on the slide differed only in how they stored data. The Event Sourcing version loaded the events, rebuilt state with List.fold object.evolve, called decide, then appended the new events. The Transaction Script version loaded the current state from a database (falling back to object.init), ran the same decide and evolve, then saved the new state. Both returned the effects to perform afterwards.
Event Sourcing on the left, Transaction Script on the right: same domain logic, different persistence.
My take: this is the part I find most useful for platform work. If decide and evolve are pure and return effects instead of running them, you can test the business logic without mocks. You can also change how you store data later without rewriting it.
Where Event Modeling comes from
Another slide put the talk in context with a short history of the ideas behind it:
- Event Modeling: Adam Dymitruk, 2018
- Event Storming: Alberto Brandolini, 2013
- CQRS: Greg Young, 2007
- Event Sourcing: Martin Fowler, 2005
- Domain-Driven Design: Eric Evans, 2003
Next to the list was an Event Modeling diagram with swimlanes of coloured sticky notes, credited on the slide to Yves Goeleven.
Fifteen years of modelling ideas on one slide, from Domain-Driven Design in 2003 to Event Modeling in 2018.
The AI track
Later, the AI track stage was getting ready for its next session. The screen read âThe AI track is made possible by Kickstart AIâ, and people were putting their headphones on.
The AI track stage between sessions, sponsored by Kickstart AI.
By the 2026 edition, AI had moved onto the keynote stage, as I wrote in my posts on the AI infrastructure keynote and Checkmarxâs AppSec session. In 2025, AI had its own sponsored track.
The evening
The day carried on into the evening. A DevWorld banner hung across a street, with balloons strung across the street behind it: âWe hope youâre having a good time!â
The DevWorld banner over the street, and a drink to end day one.
Looking back
My take, looking back at the Duck Stage slides: you donât need a framework to separate decisions from side effects. You need a type for the effect and the discipline to run it in one place. The silent-stage format is also a practical way to fit more talks into one open hall.
