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

2
votes

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.

2
entitydomain-driven-designaggregatebounded-contexts
This is the same as asking how many properties can a class have? There is no rule for this. It all depends on the domain that you are modeling. – Mohamed Bouallegue
This "question" is so broad and so poorly written (most phrases have no logic or sense in my opinion)... I think your confusions lie deeply in your understanding of the basic principles of DDD tactical design. – Paul-Sebastian Manole
@Paul-SebastianManole what's the point of your comment? Just wanna to label something "bad" ? When you're trying to say "no logic", it's fine to provide evidences, otherwise you're not constructive In my opinion, it's pretty well & fine understanding. – user8245660
I'm sorry, no ill intent. I don't think I can provide evidence of things that don't make sense to me. It would be like knowing what the author actually meant to say... or be just as confused and talk nonsense myself. But to at least try and conform to what's expected of me. The issue is that there is no saying in how many aggregates a BC should have. It all depends on the domain. SOLID, as well, has nothing to do with this perceived constraint. – Paul-Sebastian Manole

2 Answers

6
votes

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.

4
votes

How many aggregates should have a single bounded context?

All aggregates should have a single bounded context. You can almost work that out backwards - an aggregate is going to be stored in a single database, a database is going to belong to a single (micro) service, a service is going to serve a single bounded context; therefore it follows that an aggregate is going to belong to a single bounded context.

Where things can get messy: it's easy to take some broad business concept, like "order", and try to create a single representation for order that works for every bounded context. That's not the goal though -- the goal is for each context to have a representation of order that works in that context.

Common example: sales, billing, fulfillment may all care about "order", but the information that they need to share is largely just the order id, which acts as a correlation identifier so that they can coordinate conversations.

See Mauro Servienti: All of Our Aggregates Are Wrong