I usually kick off my tactical DDD training with this flipchart exercise, because there's a misconception I run into time and again: people confusing monoliths with big balls of mud.
A monolith is not an anti-pattern. A big ball of mud is. The difference? Modules. A well-designed monolith has clear module boundaries — a big ball of mud has everything tangled together.
...
And here's the thing: if you can't design proper modules in a monolith, microservices won't save you. You'll just end up with a distributed big ball of mud, which is arguably worse.
That's what this training is about. We start with this visual sense-making to make the distinction tangible, and then spend the rest of the time exploring what those modules actually are — and how Domain-Driven Design, specifically bounded contexts, helps you design them.
...
The coloured blocks on the flipchart make it click for most people. Once you can see where coupling creeps in and where boundaries should be, the conversations about architecture become much more productive.
Tomorrow, we go into one of the modules, sketch it out using Responsibility-Driven Design, and then go straight to coding.
#DomainDrivenDesign #TacticalDDD #SoftwareArchitecture #BoundedContext #SoftwareDesign
Kenny (Baas) Schwegler