Edit 2: Thinking about the problem some more I realized that "Can aggregates be used outside DDD?" was not the right question, hence I changed the title.

For the reasons described on the original post, I did not follow a DDD approach and its entity model. Still, I would like to group tightly related concepts (which would be in the same aggregate) and specifying which one is the "parent" (the root). Is there a formal way to represent what I just described other than aggregates in a DDD?

Original post

Let's say I have a domain model composed of many simple relationships like the one represented in the image. The business logic is pretty straightforward and many of the attributes are not to interact with the rest of the model - they simply exist for presentation purposes.

Applying DDD on this example would mean I had 3 entities: Author (root), Book (root) and Chapter; and 8 value objects, which would result in 11 components just for this one part. Considering that most of the attributes are irrelevant to the model (but are needed in the presentation side of things) and that using DDD would make the domain model too clustered, I opted out of the DDD entity-value object representation. This decision was also based on this comment.

Though, I feel like it would still make sense to represent the "aggregates". Is this acceptable or is it against common practice?

domain example

Edit: Seems like I failed to convey what I was referring to as I tried to keep it short. Hopefully I can do a better job this time!

My main issue with DDD is that the diagram (and future implementation) would become too clustered and hard to comprehend due to "useless" attributes flooding it rather than its performance implications (as a SE student it is enforced that we prioritize maintainability over performance).

In this example, the domain model represented in the image would go from 3 "components" to 11, 8 of which are VO that do not add any value to the comprehension of the domain. These numbers really do add up quickly as more concepts are introduced.

The question was if it is possible to apply the definition of aggregate, or its equivalent, outside DDD.

  • 2
    Since my answer was no longer relevant to the topic after the update of your question, I've decided to delete it.
    – Andy
    Commented Aug 23, 2020 at 17:40
  • The answer is yes, you can use something like aggregates outside the context of DDD. In fact, the pattern of clustering several related, collaborating object behind a Facade (root) object, and treating them as a unit of sorts is not new or uncommon in OOP, and as an organizational/design technique predates DDD. Sometimes the design of those clusters takes persistence into account. DDD (Evans 2003) took that practice and gave it a name, discussing it in the context of object lifecycle (in-memory, DB representation, reconstitution, archiving, deleting). Commented Aug 23, 2020 at 22:24
  • 2
    P.S. BTW, the concept of a Value object doesn't imply that you have to create a separate class for each of them. And if someone tells you differently, they are wrong (there may be some framework or coding convention that makes you do that, but the concept itself isn't about that at all). E.g., things like name, age, gender, number of pages or release date are perfectly fine value object without you having to do anything special. Commented Aug 23, 2020 at 22:29

2 Answers 2


Reading the question, I wonder if there's not a misunderstanding.

Indeed, from the DDD perspective there's 1 aggregate, 3 entities, and 8 value objects. But this does not mean that there must be a combinatorial explosion of the components:

  • a value object may require its own type, if it's a complex value made of more than one component (example: a monetary value is made of an amount and a currency);
  • but a value object does not require you to over-engineer your solution and start to systematically create new types for age, title, name if these are just simple integers and strings (you can, if you'd like to add some constraints, such as age between 0 and 199, but you really don't have to).

The same applies by the way to the UML class diagram: you can model each property as a separate class that would be associated to the class that owns the property; it's a valid modelling choice that would semantically mean the same thing, but it would just make the visual representation unreadable.

So a DDD does not mean more complexity and less performance. It means on the contrary more reliability: the key is to empower the aggregate to ensure the consistency and the invariants of all these tightly interrelated classes and objects.

Now if you like the concept, but do not like the rest of the DDD approach, for example if you'd prefer to use table gateways or active records instead of repositories, you can go for such an alternate design if you're aware of their pros and cons. You can even reuse the invariant knowledge. But it's just that you won't have the same level of control on the aggregate if your design would allow to address each entity separately.


Not only can aggregates be used outside of DDD but they often are. Conceptually the Controller in MVC patterns and the Repository can function as an Aggregate that encapsulates all the behaviours, states and interactions for a bounded context.

There are many implementations of MCV or Repository that narrow the scope to a single entity or value object, that doesn't make them good Aggregate implementations but they are potential candidates.

In fact if you take a higher level view, each service in microservice architecture is an Aggregate, it's just that typically in DDD we narrow the context to something in between these two extremes.

Even if your chosen design methodology isn't DDD, that does not mean that your design cannot benefit from implementing some of the sage guidance that DDD has to offer.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.