Domain modelling, DDD & Event Storming

Event Storming is a facilitated, timeline-first workshop: domain events on the wall (or board), ordered as they happen in the real world, then policies, commands, read models, and external systems layered on until ambiguity has nowhere to hide. It’s deliberately inclusive—your best experts are often not the loudest engineers in the room—and it surfaces integration pain, inconsistent language, and “we never agreed who owns this” early.

Domain-Driven Design turns those insights into durable design: bounded contexts with explicit relationships, a ubiquitous language that appears in code and UI, and strategic choices about where to invest in a rich domain model vs where thin CRUD is honest. DDD is not an excuse for over-engineering; it’s a way to keep big systems coherent as they grow.

I use this combination when organisations are about to split a monolith, launch a new product line, merge teams after M&A, or unblock a programme that keeps re-planning because stakeholders mean different things by the same words. The pillar narrative is easy to forward: “here’s how we align before we commit headcount and cloud spend.”

Expect facilitation, crisp artefacts (photos, Miro exports, short written summary), and help translating outcomes into backlogs, team boundaries, and technical spikes—not a slide deck that ages in a week.