That software and organizations have boundaries and that they matter is true but is too obvious to be interesting. DDD has little to say about the most crucial aspect of those boundaries - where the boundaries go and why.

There is a shared semantic model both inside a boundary and outside. However, DDD has relatively little to say about the most crucial part of that too - how to shape and define that language.

DDD does, however, have a lot to say about how to misapply certain design patterns.

> DDD has little to say about the most crucial aspect of those boundaries - where the boundaries go and why.

The whole point of DDD is that there can't be a one-size-fits-all answer to these questions. Instead, they give you some questions you need to think about, and tools that might help you find answers.

The whole point appears to be that there IS a one size fits all set of design patterns once you've got the right "bounded contexts" and the right "ubiquitous language".

It doesn't have anything interesting to say about either one of those things though. The whole idea appears to be a set up for a bunch of design patterns.

There is definitely a part of the DDD community that wants to do it that way. I call it “domain driven design driven design”. But the big names in DDD have all explicitly said that’s wrong.

> true but is too obvious to be interesting.

I think most orgs don’t act this way, which suggests to me that it’s not actually obvious.

> However, DDD has relatively little to say about the most crucial part of that too - how to shape and define that language.

I don’t think this is actually true. (Relative to what? Other architectural systems?) It strongly advocates for a process of identifying Entities, by iteratively working worth the domain experts. The core entities should be domain objects not technical concepts. (The opposite conceptual pattern I often see is making the core objects generic functional/behavioral/logical operations with the business rules as config that’s passed through. Maybe more sensical for pure technical users, but gibberish for business users. Perhaps valid for building a generic business logic platform like SAP though!) The concept of Ubiquitous Language mandates that you have a dialog with domain experts, and keep doing that as the domain evolves. The concept of a Bounded Context gives guidance on how to judge between different potential splits in your domain, which is more than most architectural frameworks offer. All of these mean you are better placed to agree on boundaries that make sense to the business/domain as well as technical functions.

I think Aggregates and Repositories are a good low-level concepts for working with Domain-driven architectures, but they don’t participate in the higher-level organizational discourse.