Event-driven architecture helps you reflect the business process in code and makes it easier to work with the business. It can also reduce dependencies between parts of the system, but only if the system is split well.
\nWithout good modelling, you get the worst kind of dependencies: hidden ones. Services look independent, yet a change in one breaks another.
\nA good model is only half the job, though. EventStorming sticky notes won’t tell you whether you need a queue, or what happens when a message arrives twice or out of order.
\nThey won’t tell you how to change a contract without breaking another team’s service either. The team discusses the business process together, and then everyone goes back to the code and decides alone how to coordinate the process, which queue to use and how to ensure delivery, ordering, consistency and idempotency. The consequences of those decisions usually show up only in production, when messages get lost, duplicated or processed in the wrong order.
\nIn this workshop, we’ll go all the way from business requirements, through the process model and the technical model, to the implementation. Step by step, we’ll look at how requirements shape the technical solution. How do you split a system so that the dependencies between its parts are explicit? When does a queue help, and when does it only add complexity? How do you provide the guarantees the business actually needs? How do you test a flow and catch incompatible contract changes before another team notices them?
\nThroughout the workshop, we work on a single distributed business process, from the first sticky note to running code. We also cover some topics with smaller, separate examples.
\nNo long lectures. Instead, there are lots of small tasks and group work. EventStorming and other modelling techniques aren’t the goal here. They’re tools for talking about the process and about how to turn the model into a working system. Participants in previous editions most often named exactly this path, from EventStorming to code examples, as the most useful part of the workshop.
\nAlong the way, we’ll also look at where GenAI helps with modelling and implementation, and where its output needs careful checking.
\n23 and 24 November, and 30 November and 1 December 2026, online, in English, PLN 699 EUR.
\nI’m an independent architect and consultant, and I’ve been designing and building business systems for over 18 years. I help teams design event-driven systems and run training on Event Sourcing, CQRS and Event-Driven Architecture. I’ve applied these approaches in my own projects. I’ve seen how they make systems easier to scale and maintain, and also where they stop paying off.
\nBusiness processes are rarely easy to understand. Knowledge about them is spread across many people, and requirements arrive in fragments. Event-driven architecture helps put them in order and reflect them in code. Even when you manage to model them well, you still have to translate the model into architecture and implementation, and that’s a challenge of its own. This workshop covers both.
\nI also know the problems covered in this workshop from the tooling side. I created Emmett, I was one of the maintainers of Marten and I contributed to EventStoreDB. On GitHub, I share samples and exercises in .NET, Node.js and Java.
\nI write regularly about the workshop topics on this blog and in the Architecture Weekly newsletter, for example:
\nWeek 1: 23 and 24 November 2026
\nWeek 2: 30 November and 1 December 2026
\nAll sessions run from 9:00 to 15:00 CET. The workshop is run in English.
\nPrice: EUR 699 + VAT.
\nLimited to 12 places. The workshop will go ahead once at least 5 people have signed up.
\nSo, have I convinced you?
\n