Service
Domain-Driven Design & Event Storming
Facilitated workshops and follow-through: bounded contexts, ubiquitous language, and collaborative modelling so product, engineering, and domain experts align before big tech bets.
Discuss this for your team?
Tell me about your context—I'll suggest a sensible first step, whether that's a short call or a scoped piece of work.
Most delivery pain is not “bad developers”—it’s fuzzy boundaries between parts of the business, overloaded words that mean different things in every meeting, and roadmaps that skip the hard conversation about what the system actually is. Domain-Driven Design (DDD) gives you language and modelling tools for that. Event Storming is one of the fastest ways I know to get product, engineering, and domain experts looking at the same picture in a room (or on a Miro board).
I run sessions from half-day discovery through multi-day deep dives, depending on scope: greenfield products, carve-outs, legacy strangler plans, or “we’re about to replatform and nobody agrees what we’re building.” Outcomes typically include a shared timeline of domain events, visible hotspots (policy, contention, integration), candidate bounded contexts, and a pragmatic next step—not a wall of sticky notes nobody uses.
After the workshop, I help teams connect the model to delivery: where contexts become services or modules, how APIs and data ownership should look, what belongs in a platform team vs stream-aligned teams, and how to keep the language alive in ADRs, backlogs, and reviews. This pairs naturally with engineering leadership, platform modernisation, and culture work when org design has to match the domain model.
If you’re unsure whether to start with Event Storming or a lighter architecture review, get in touch—we’ll pick a format that fits your constraints and decision horizon.