DDD - Value Object flavor of an Entity-CodePudding

I've seen some DDD projects with value object representations of entities. They usually appear like EmployeeDetail, EmployeeDescriptor, EmployeeRecord, etc. Sometimes it holds the entity ID, sometimes not.

Is that a pattern? If yes, does it have a name? What are the use cases? Are they value objects, parameter objects, or anything else? Are they referenced in the domain model (as property) or are they "floating" just as parameters and returns of methods?

Going beyond...

I wonder if I can define any aggregate as an ID BODY (detail, descriptor, etc) METHODS (behavior).

public class Employee {
    private EmployeeID id;
    private EmployeeDetail detail; //the "body"
}

Could I design my aggregates like this to avoid code duplication when using this kind of object?

The immediate advantage of doing this is to avoid those methods with too many parameters in the aggregate factory method.

public class Employee {
   ...
   public static Employee from(EmployeeID id, EmployeeDetail detail){...};
}

instead of

public class Employee {
   ...
   public static Employee from(EmployeeID id,   10 Value Objects here){...};
}

What do you think?

CodePudding user response：

What you're proposing is the idiomatic (via case classes) approach to modeling an aggregate in Scala: you have an ID essentially pointing to a mutable container of an immutable object graph representing the state (and likely some static functions for defining the state transitions). You are moving away from the more traditional OOP conceptions of domain-driven design to the more FP conceptions (come to the dark side... ;) ).

If doing this, you'll typically want to partition the state so that operations on the aggregate will [as] rarely [as possible] change multiple branches of the state, which enables reuse of as much of the previous object graph as possible.

CodePudding user response：

Could I design my aggregates like this to avoid code duplication when using this kind of object?

What you are proposing is representing the entire entity except its id as a 'bulky' value object. A concept or object's place in your domain (finding that involves defining your bounded contexts and their ubiquitous languages) dictates whether it is treated as a value object or an entity, not coding convenience.

However, if you go with your scheme as a general principle, you risk tangling unrelated data into a single value object. That leads to many conceptual and technical difficulties. Take updating an entity for example. Entities are designed to evolve in their lifecycle in response to operations performed on it. Each operation updates only the relevant properties of an entity. With your solution, for any operations, you have to construct a new value object (as value objects are defined to be immutable) as replacement, potentially copying many irrelevant data.

The examples you are citing are most likely entities with only one value object attribute.