DDD - Value Object flavor of an Entity

Question

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?

Answer 1

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.