DDD: Entity or Value Object?

Depending on the context certain concept may be modeled as an entity or as a value. It could be both in different bounded contexts. To me, good heuristics to choose between entities and values are life cycle and mutability. Values are immutable, represent constants. A color is a good example (thanks Alfredo). If color changes from red to blue it's not the red color anymore but something else. The cost of returning a new instance when color changes is cheap:

  1. Color yellow = red.mixWith(green);

When returning a whole new objects costs many lines of code and memory that could be a sign that it's probably better modeling as an entity. If we care about changes that could be another sign. Recently we had to model a draft invoice. From the point of view of the business a draft doesn't require a unique number, only the final invoice has to have a unique sequential number (identity). So I thought we could model the draft as a value. After all if two drafts consist of the same customer and the same lines, the business could not tell the difference between the two. We chose a value object but then every time a new line went into the draft we had to create a new one, copying all the existing lines. Too much code for such a simple operation. Finally we changed the design modeling the draft as an entity.

Questioning the design made us speak to the domain experts - “how would you search for a certain draft? If two draft contains exactly the same how do you differentiate them?”. And they decided the application should allow for just a single draft per customer. It simplified the application even though eventually we used an entity.

As the object changes, we may be interested in tracking why, who and by whom changes were made” - This is a good heuristic to think of an entity.

When the entity's identity generation is delayed until it's persisted, we might have to implement the equals and hashCode methods as if it was a value object to avoid bugs”. This kind of workarounds make the distinction fuzzy.

I currently think that choosing an entity or a value boils down to good object oriented and simple design. Value objects are older than DDD, I believe the term was coined by Ward Cunningham. Even if the object is an entity, I try to avoid getters and setters as much as I can. Rather than reading information from object properties, objects may communicate with each other by sending messages.

Things to remember from the two chapters:

  • I like the trick of Layer Supertype on page 187 to hide a surrogate identity from entity's consumers.
  • I find the idea of “role interfaces” on page 203 quite handy to expose only certain behavior to consumers.
  1.  
  2. class Customer : AddOrder, MakePreferred {
  3. }
  4.  
  5. var customer = Repository.Find<AddOrder>(customerId);
  6. customer.AddOrder(order);
  7.  
  • Values advantages: “Value types that measure, quantify or describe things are easier to create, test, use, optimize and maintain”
  • Limit a value to depend on and understand its own type and the types of its attributes.
  • Pass only values as parameters to value methods.
  • I like how he uses the Java enum to implement the State pattern on page 235 (he calls it Standard Type). Java enums are really powerful.
Enjoyed reading this post?
Subscribe to the RSS feed and have all new posts delivered straight to you.
  • http://josecelano.com/ Jose Celano

    Hi Carlos, I have found a lot of posts about Entities vs Value Objects but what do you thing about Enums?. PHP does not support Enums and there are libraries like these:

    https://github.com/marc-mabe/php-enum
    https://github.com/eloquent/enumeration

    It is very common to find/write code like this:

    class Customer {

    const STATE_1 = ‘state-1’;
    const STATE_2 = ‘state-2’;

    public static $STATES = [
    self::STATE_1 => self::STATE_1 ,
    self::STATE_2 => self::STATE_2 ,
    ];

    private $name;
    private $state;// Valid values are defined as const

    public function changeStateTo($newState){
    // TODO: check valid state
    }
    }

    Using those libraries you can avoid duplicate code and use type hints on parameters.

    My questions are:

    – Do you thing Enums are Value Objects?
    – Do you prefer to use Enums when language supports it?
    – When to use Enums and when to use Value Objects?

    In this post https://pboop.wordpress.com/2011/11/15/enums-considered-a-codesmell/ the author thinks Enums are codesmells.

    Why not to use always a Value Object? It can be converted to an entity in the future is neeed. For example, state can become more complex and Customer could have one mehtod which depends on state.

    Perhaps you should use a value Object always and Enum should only be the declaration for valid values inside that Value Object.

  • http://josecelano.com/ Jose Celano

    This a good post describing how to store Value Objects in database if you are using Doctrine:

    http://welcometothebundle.com/persist-the-money-doctrine-value-object/