DDD: must all Aggregates model relationships, or they can be “shallow”?

Question

Sometimes my Aggregate will be very simple; some scenarios are simply not complex enough to require deep trees of objects and relations.

Consider a Website Monitoring application, which periodically pings a URL to check if it is alive.

The Web App will have:

• Id
• FriendlyName
• ‎URL
• ‎IsAlive

It doesn't have much data, doesn't have child objects (except maybe for URL being a Value Object) and will certainly not have much invariants - if any - to enforce either, at least not at this time.

Now some say that because it is not modelling a more complex model, with relationships and internals and whatnot, it is not an Aggregate, it is only an Entity.

The thing is, I don't think that complexity or size should be dictating if it's an Aggregate, Entity or Value Object, but rather its MEANING.

For the Web Application Monitoring domain, that Web App "entity" is the root model, it's what is going to be returned from a Repository. If the domain expert brings new requirements, they will be related to that Web App model.

So, for me, I believe it makes it a WebAppAggregate, rather than a WebAppEntity.

---

Question: is my line of thinking correct, or did I get it all wrong? Thanks in advance.

Answer 1

The thing is, I don't think that complexity or size should be dictating if it's an Aggregate, Entity or Value Object, but rather its MEANING.

The thing is, these terms have definitions spelled out in the blue book

From chapter Five. A Model Expressed in Software

Does an object represent something with continuity and identity--something that is tracked through different states or even across different implementations? Or is it an attribute that describes the state of something else? This is the basic distinction between an ENTITY and a VALUE OBJECT.

From chapter Six. The Life Cycle of a Domain Object.

AGGREGATES mark off the scope within which invariants have to be maintained at every stage of the life cycle.

An AGGREGATE is a cluster of associated objects that we treat as a unit for the purpose of data changes.

It's entirely consistent to have an aggregate that contains only a single entity, that entity having only a single interesting property, and only simple behaviors that change that property from one value to another.

I would like to know your thoughts on my solution attempt.

The basic shape is fine: your WebApp entity is also the root of the aggregate, which is consistent with the pattern as described by Evans.

Raising the domain event in the constructor may be an error; it's certainly a code smell (raising a domain event certainly counts as real work).

Answer 2

The thing is, I don't think that complexity or size should be dictating if it's an Aggregate, Entity or Value Object, but rather its MEANING.

---

I read someplace you're not supposed to return anything except Aggregates from the Repository.

You seem to be thinking in the terms that an item is either Aggregate, an Entity, or a Value Object. However, the notion of Aggregate is not the same as Entity and Value Object; Aggregate is not a third alternative but a different notion.

An aggregate is a logical collection of Entities (and Value Objects) and their relationships. An aggregate has a single special entity, called the root entity. This root entity is referred to as the Aggregate Root. It is the only entity within the Aggregate that is allowed to be referred to from outside of that aggregate. As the point of contact from outside of the aggregate, the root is generally expected to enforce integrity of the aggregate.

Note that the Aggregate Root is an Entity! The Aggregate itself is the logical collection of related entities. It is a boundary around these entities (with some rules).

If you don't have a collection, you don't have an Aggregate. But that's fine, you simply have an entity.

(In my opinion it is also reasonable to think of a lone entity having an identity that can be referred to, as a degenerate case of an Aggregate having only one entity, the root entity, if you like.)

Even if you do have a collection you still have to have at least one Entity, in this case one of the entities must be the root entity, which is your Aggregate Root. Again Aggregate Root is an Entity whereas an Aggregate is a logical collection (having an Aggregate Root).