Domain-Driven Design – Must All Aggregates Model Relationships?

domain-driven-designdomain-modeldomain-objects

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.

Best Answer

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).

Related Topic