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

No . It is very common to try to understand the DDD design patterns by confusing them with object-oriented design patterns; and this usually leads to deception.

Although in practice what we see most is DDD being implemented using object orientation (lie, in practice we almost do not see DDD) , strictly object orientation is not even a requirement - DDD can be implemented using other paradigms.

  

What are aggregations really?

  

How do we identify aggregations when making the domain template?

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

• Value objects: They do not have any identity, so they will always be part of an entity. They will be part of an aggregation when your entity is the root of this aggregation or your entity is part of this aggregation.

• Entities : they have 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 another 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 must 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 depends on other entities (which do not have a global identity) to help describe it. These other entities will then be aggregated to this root entity - and hence we have an aggregation.

The domain determines which objects have identity and which have global identity. Those with global identity may be the root of aggregation and those whose identity is dependent on this root entity will be aggregated to it. Value objects, in turn, are always close to your entity.

Aggregation example

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 workbook has a global identity in the domain or template. Your identity is your name plus the name of its author.

Reviews also have identity, which is the name of the client or publisher, and possibly the date of publication. But see 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 serves no more than one book and will not exist without a book.

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

As far as I can tell from the concept, agregado is very similar to the composition in OOP.

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

In this, we have the aggregate car, with the other three, motor, ports and wheels being classes added to the car class.

A carro object has ports, motor, and wheels, and these parts have no life outside the object , that is, they are subordinate to the object carro .

If a client wants to manipulate a port or engine, it will have to do this using the object carro , but can not when using the selected port or engine.

Responding to other questions ...

An aggregate would be a set of classes from an aggregation relation. As the composition is a more restricted aggregation (in the aggregation, the parts have life out of the whole, in the composition, no )

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