When to model an aggregate's entities as part of a value object?

Question

I've read a lot about Domain Driven Design including books from Eric Evans and Vaughn Vernon. So I am familiar with the concepts Aggregate Root, Entity, and Value Object.

But while I was modeling some domain model using Domain Driven Design approach a question arose which I never had before. I realized that I could model an aggregate root's state entirely as a value object which also includes the child entities. Let me first show you the "normal" approach:

class EntityDataVO {}

class Entity {
    String id;
    EntityDataVO data;

    Entity(String id, EntityDataVO data) {
        this.id = id;
        this.data = data;
    }

    void update(EntityDataVO data) {
        this.data = data;
    }
}

class AggregateRoot1 {
    private Map<String, Entity> entities = new HashMap<>();

    void addEntity(String id, EntityDataVO data) {
        this.entities.put(id, new Entity(id, data));
    }

    void updateEntity(String id, EntityDataVO data) {
        this.entities.get(id).update(data);
    }
}

There is an Entity class with an id and a value object EntityDataVO. The AggregateRoot1 class creates instances of this class and keeps a list of them. Updates to specific entities are delegated to the Entityclass.

Now let me show you the alternative modeling approach:

class AggregateRootDataVO {
    private Map<String, EntityDataVO> entities = new HashMap<>();

    AggregateRootDataVO addEntity(String id, EntityDataVO data) {
        var rootData = new AggregateRootDataVO();
        rootData.entities = new HashMap<>(entities);
        rootData.entities.put(id, data);
        return rootData;
    }

    AggregateRootDataVO updateEntity(String id, EntityDataVO data) {
        var rootData = new AggregateRootDataVO();
        rootData.entities = new HashMap<>(entities);
        rootData.entities.put(id, data);
        return rootData;
    }
}

class AggregateRoot2 {
    private AggregateRootDataVO data;

    void addEntity(String id, EntityDataVO data) {
        this.data = this.data.addEntity(id, data);
    }

    void updateEntity(String id, EntityDataVO data) {
        this.data = this.data.updateEntity(id, data);
    }
}

In this case, the list of entities is "encoded" into the AggregateRoot2's value object AggregateRootDataVO. As you can see, the value object's identity is defined by its members which are, of course, value objects by themselves. So two instances of this class with an equal internal map of entities are equal and I wouldn`t care which one to use.

Now I am confused. I really have no idea which alternative I should use. The second approach has definitely an advantage. The complete aggregate's state is represented as a value object. So it is easy to serialize it in order to send it over the network. For instance, a backend service could send it to a GUI frontend and the latter would see the complete aggregate's state. This is not true for the first approach implemented in AggregateRoot1. In that case I would have to define a DTO (Data Transfer Object) for that purpose which would look similar to the AggregateRootDataVO class.

I wonder what others think about those two modeling approaches and which one they'd prefer under what circumstances. Currently, I really don't know which one I should prefer. In fact, I am tempted to always prefer the second approach when there is no good reason against it, because I like to deal with value objects and their nice properties.

Answer 1

I realized that I could model an aggregate root's state entirely as a value object which also includes the child entities.

Yes.

Fundamentally, the aggregate root is responsible for its entire data model. Carving that data model up into separate responsibilities is "arbitrary".

So how do we choose? I think one of the interesting ideas out there currently is Ward Cunningham's explanation of technical debt:

if we failed to make our program align with what we then understood to be the proper way to think about our financial objects, then we were gonna continually stumble over that disagreement and that would slow us down which was like paying interest on a loan.

More generally, while we "can" do anything that produces the right behaviors. But if we choose a design that is aligned with the "proper way" to think about our domain, we are going to have a much easier time managing future change.

In particular, when the domain expert asks us for a "small" change, the change to the implementation is more likely to be small if our design is aligned with the way the expert thinks about the domain.

Answer 2

DDD will not provide an idiomatic answer to your question. Your first option requires less code. Go with that.

I don't see an important difference between the two examples you have provided. They are equal implementations of the same Aggregate. Similarly, other than affording the exact signature and terseness for your updateEntity method, I don't see a reason for the existence of EntityDataVO.

The key insight here is that the consumers of either object (Entity and Aggregate) will not know (or care) how the internals of your domain are implemented, so why bother spending (wasting) time on this? You should choose the most straightforward method available that meets your business requirements.

On a broader note, because you are abusing the term, we need to provide some clarity. Your VO's aren't really Value Objects in the DDD sense, rather, technical artifacts used for your own internal implementation of immutability. A Value Object is not just an immutable object. It is also a domain concept. This means, in a business sense, it is a useful representation of and/or to your domain.

Your examples are only useful to their wrappers. There's nothing wrong with that! If you want to model your entity's internal machinations as immutable using the approach you have outlined above, that is your prerogative. Though from a DDD standpoint it makes no difference.