entitydomain-driven-designaggregatebounded-contexts

DDD: How many aggregates should have a single bounded context?


How many aggregates should have a single bounded context?

I'm asking this question due the reason, that the information from books and other resources are too broad/abstract.

I suppose, that it depends on certain domain model and its structure. How many bounded contexts do have a domain model? How many entities there are in each bounded context. I suppose, that all these questions make dependency on that fact, how many aggregates should be in a single bounded context.

Also, if to recall the SOLID principles and the common idea to have the small loosely coupled pieces of code. I suppose, that it's fine to have maximum 3-4 aggregates per single bounded context. If there are more aggregates in single bounded context, then there are probably some issues with the software design.

I'm reading the Vernon's book right now about DDD, but it's rather difficult to understand how to design certainly such things.


Solution

  • The trite answer is “just enough, but not too many”. There is no real guidance on how many aggregates to put in a bounded context.

    The thing that drives aggregates and entities is the Ubiquitous Language that is used to describe the context. The Ubiquitous Language is different for each context, and the entities and aggregate roots needed in the context can be found in the nouns used in the language. Once you have the domain fully described by the language, count up the nouns that have a special meaning in that language and you have a count of the entities necessary.

    Bear in mind, though, that I've rarely come across a bounded context that was "fully described". The goal is "described fully enough for this release". Therefore for any release the number of entities won't be "enough" and you'll probably have plans of adding more. Whether those plans ever rise to the top of the priority queue is another question.