Domain-Driven Design can be scary

In my early years, I worked with some incredibly talented people. They introduced me to emerging concepts, such as unit testing, now considered best practices.

Domain-Driven Design (DDD) was one of them, but I struggled. I remember finding it abstract and disconnected from the projects I was working on. What does a bounded context mean? I picked up the Big Blue Book but struggled to get through it, which triggered a fair amount of imposter syndrome.

Years of hands-on experience later, the pieces fell into place. Yet, I still approach DDD implementations with healthy scepticism. While I value its core principles, its terminology often creates unnecessary complexity. Bounded contexts, aggregate roots, ubiquitous language—these terms aim to bring clarity, yet for less experienced people, they can make things more complex instead.

Naming things is hard, but how about explaining bounded contexts as modules? Using ubiquitous language means agreeing on the correct term the business uses and using that one as well. Seniors should be mindful of their terminology when collaborating with less experienced team members. What is common knowledge for them can be a whole new concept for others, and they don't always dare to ask questions. Simpler terms often serve our team and, indirectly, the product we are building better.