A hands-on Domain-Driven Design track — EventStorming, strategic architecture, and tactical implementation in Java and .NET carried across one running case, from sticky notes to a proof of concept.
Domain-Driven Design Track
Most DDD training starts with the patterns, entities, aggregates, repositories, and leaves you with a tidy tactical toolbox and no idea where to point it. Ours starts from the harder half: what is the domain actually doing, where are its real boundaries, and which complexity is worth modelling at all?
We’ve run this internally for our own consultants, led by our competence-center coaches and built around a single running case: Icetenium, a fictional ice-cream sales platform. From sticky notes on a wall to a proof of concept in Java and .NET, the same domain is carried across every session, so the patterns are chosen for a reason instead of cargo-culted. This is that program, packaged into modules you can compose into a track for your team.
EventStorming
Before a line of code, get everyone in front of the same wall. We map the domain the way Alberto Brandolini’s EventStorming does it: domain events on orange stickies, the commands and actors that cause them, the policies that react, and, the most valuable colour, the hotspots where the business itself doesn’t agree.
We run all three levels as the team needs them: Big Picture to see the whole landscape, Process Modelling to walk a flow end to end, and Design Level to get close enough to code. The point isn’t the post-its. It’s that the team and the domain experts build a shared, ubiquitous language and that the seams between subdomains start to show themselves.
For Icetenium, this is where “selling ice cream” stops being one thing and splits into ordering, inventory, routing, and payments.
DDD Architecture
Strategic design, then structure. We take the bounded contexts that surfaced in the EventStorming and turn them into an architecture you can actually build and scale.
- Bounded contexts & subdomains: telling core from supporting from generic, and spending your best people accordingly.
- Context mapping: the relationships between contexts: partnership, shared kernel, customer-supplier, conformist, and the anti-corruption layer that keeps a clean model from being poisoned by a messy upstream one.
- Architecture styles for DDD: layered, Onion & Hexagonal (ports and adapters), and where CQRS and event sourcing earn their keep, and where they don’t.
This module pairs directly with our Architecture Track; DDD is where its bounded contexts get their boundaries.
Implementing DDD
The tactical patterns, hands-on, in code. Entities and value objects, aggregates and their roots (and why they’re the consistency boundary that keeps you honest), repositories, domain services, factories, and domain events.
We build a proof of concept for Icetenium in both Java and .NET, grounded in the decisions from the earlier sessions, so the code reflects the model instead of fighting it. Pragmatic, not dogmatic: we’re explicit about when full tactical DDD is overkill and a simpler design wins.
The Book Club
Running alongside the track, our internal book club is reading Vaughn Vernon’s Implementing Domain-Driven Design, the “red book”, across four sessions in 2026. Theory from the page, argued against the code we’re actually writing. It’s how the track’s ideas get pressure-tested between sessions instead of fading after the workshop.
Why this track works
Interested in running the DDD Track for your team?
We tailor this track to your domain, your constraints, and your team’s level – from a single module to the full curriculum, on-site or remote.
Discover more events
Arrow Tag
We kicked off the season with Arrow Tag in Aalst: quick reflexes, smart tactics, and just the right amount of chaos.
