What are DDD aggregates and how to identify them?

Question

In DDD there is the notion of aggregate. A definition I’ve seen around is as follows:

Compounds of Entities or Objects of Values that are encapsulated in a single class. The Aggregate serves to maintain the integrity of the model. We have chosen a class to serve as the root of the Aggregate. When some client wants to manipulate data from one of the classes that make up the Aggregate, this manipulation can only be done through the root.

So basically the idea of DDD aggregates is equivalent to the idea of composition in object orientation? The composition relationship between two objects is basically when one acts as part and the other acts as whole. So, when we make a composition is making an aggregate, and the "whole" is the aggregate? And in this case what is the root?

What are actually aggregates? Also, how do we identify aggregates when making the domain model?

Answer 1

So basically the idea of DDD aggregation is equivalent to the idea of object-oriented composition?

Not. It’s very common to try to understand the DDD’s Patterns design by confusing them with object-oriented Patterns design; and this usually leads to mistakes.

Although in practice what we see most is DDD being implementing using object orientation _{(lie, in practice we hardly see DDD)}, a rigor the orientation to objects is even a requirement - DDD can be implemented using other paradigms.

What really are aggregations?

In DDD, aggregation is the structuring of entities and value objects in a cohesive manner in order to ensure the expressiveness of the domain and the integrity of these objects, since access to them can only be made from the entide root.

How we identify aggregations when making the domain model?

Let’s take a look at the basic structure of an aggregation:

-> Entidade Raiz
    -> Entidade agregada
        -> Objetos de valor
    -> Entidade agregada
        -> Objetos de valor
    -> Objetos de valor

• Valuables: they have no identity, so they will always be part of an entity. They will be part of an aggregation at the time your entity is the root of this aggregation or your entity is part of this aggregation.

• Entities: they have a global identity in the domain (or global in context in the case of a domain with more than one model - see bounded context). That is, you are able to differentiate one object from the other by its identity and not just by its characteristics.

• Entities that are part of an aggregation: They have identity, but not global. To make sense in the domain, their identity needs to be preceded by the identity of another entity (a "parent entity", so to speak).

• Root entities: an entity with a global identity will be the root of an aggregation if it relies on other entities (that do not have a global identity) to help describe it. These other entities will then be aggregated to this root entity - and then we have an aggregation.

The domain determines which objects have identity and which have global identity. Those who have global identity can be the root of an aggregation and those whose identity is dependent on this root entity will be added to it. The objects of value, in turn, are always together of their entity.

Example of aggregation

An example in a certain domain or model could be:

-> Livro (entidade raiz)
    -> Reviews de clientes (entidades agregadas)
    -> Reviews editoriais (entidades agregadas)
    -> Formatos disponíveis - papel, kindle, pdf (objetos de valor)

In this case, the book has a global identity in the domain or model. Its identity is its name plus the name of its author.

Views also have an identity, which is the name of the client or the editorial entity, and eventually the date of publication. But note that the identity of a review only makes sense if preceded by the identity of the book itself - although it is important to identify each review of a book (who wrote the review and when), it is not for more than a book and will not exist without a book.

Already the available formats have no identity - a book is simply available in some of the existing formats.

Answer 2

From what I could understand of the concept, the agregado is very similar to POO composition.

Let’s suppose a car, which has engine, doors and wheels.

In that, we have the aggregate car, with the other three, engine, doors and wheels being classes added to the car class.

An object carro has doors, engine and wheels, and those parts have no life outside the object, that is, they are subordinated to the object carro.

If a customer wants to manipulate a door or an engine, he will have to do so using the object carro, but will not be able when using the selected port or engine.

Answering the other questions...

An aggregate would be a set of classes derived from an aggregation relation. As composition is a more restricted aggregation (in aggregation, the parts have life outside the whole, in composition, náo)

You can identify an aggregate in the domain model taking into account the database, for example, whether you will store different types of doors, wheels and engines in the system, and cars can make use of different combinations of these parts, you can make use of that aggregate I mentioned, a car with doors, engines and tires.