Are DDD Aggregates classes or are they implicit?

Question

I mean, is there any PersonAggregate class? I understand it doesn't exist. I only have an entity acting as aggregate root. Is it correct?

Answer 1

Not in domain-driven design. That would be exposing technological jargon, essentially implementation detail, to the domain experts

Answer 2

I only have an entity acting as aggregate root. Is it correct?

That's correct.

The aggregate is implicit - it's the boundary that separates two disjoint sets of state that can be modified independently of each other. Equivalently, the aggregate is a graph of business state within a model that can be modified without consulting state outside the graph, and vice versa.

The aggregate root is explicit. That's the single entity in the graph that is exposed - which is to say that it serves as the entry point through which all modifications to the graph must pass.

Hypothetically, you could implement an aggregate that has two different exposed entities that can each execute commands to modify the state; Evans introduced the notion of a single aggregate root because multiple entry points is difficult to get correct.

Answer 3

My understanding is an Aggregate Root is an Entity but an Entity might not be an Aggregate Root. Therefore, I view 'Aggregate Root' as more of a stereotype.

Answer 4

I have seen both solutions used in projects, but most often people do not use this suffix.

One interesting solution for this is make aggregate classes public and non-aggregate classes package(default). You'd see directly from your IDE which classes have which visibility and you can determine easily where is an aggregate. Additionally non-public class cannot be used outside package which is an original intent.