Is there an equivalent to "aggregate" outside DDD?

Question

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?

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.

Answer 1

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.