I think this article skips the most important aspect of DDD. Reducing Complexity. If you’re building simple systems, you don’t need DDD and Evans has always b

I think this article skips the most important aspect of DDD. Reducing Complexity. If you’re building simple systems, you don’t need DDD and Evans has always been clear about that. But when you have a complex system, using DDD to “pull it apart” is highly effective. What you build from the parts is subject to that rule as well. If you end up with ten boundaries and some of them are simple, use simple tools. DDD isn’t a religion. It’s meant to get architects to stop designing monoliths that we know have costly lifespans. It’s also meant to get us modeling with our business partners with tools like Event Storming and truly understanding strategic opportunities. DDD isn’t just about root aggregates and value objects. It’s a communication tool and a pretty damn good one.