9

I've read countless posts on differences between Entities and Value objects and while I do think that at least conceptually I understand how the two differ, it appears that in some of these posts authors consider a particular domain concept to be a VO simply because it is immutable ( thus its state will never change, at least within that particular domain model ).

Do you agree that if the state of an object will never change within particular domain model, then this object should never be an entity? Why?

|improve this question
  • I've got to learn some DDD so that I can answer some of these questions intelligently. I suspect that the difficulty many software developers have with simple concepts like this arises from the mistaken notion that DDD is a programming methodology. – Robert Harvey Jan 8 '14 at 21:01
4

Going by the book (Evans, 2004), "An object defined primarily by its identity is called an ENTITY". This definition is independent of whether the object is mutable or immutable. I think it's much less likely for an immutable object to be an entity in a given domain, so it's a useful heuristic for deciding whether an object is a "value object" or an "entity", but that's not part of the definition.

For example, let's say you have an entity representing an employee, who may or may not have a direct supervisor. If you decide to represent the idea of not having a direct supervisor as being a reference to a "null" supervisor object, then the "null" supervisor object is reasonably considered an entity. And you could probably make this "null" object immutable.

|improve this answer
  • 1
    +1 The manager may be read only (immutable) in a particular context or subdomain, but that doesn't mean it has no identity. – Adrian Schneider Jan 8 '14 at 22:55
  • Forgive me for being dense, but I don't completely understand your supervisor example. Are you saying that in domain we would have two supervisor-related concepts? One concept would represent supervisors which do have employees they supervise ( in code this concept would be implemented as mutable Supervisor class ) while the other concept would describe supervisor which don't supervise any employees ( and this concept would be implemented as null in code )? – bckpwrld Jan 8 '14 at 23:44
  • @bckpwrld No, he surely means a Null Object. – maaartinus Sep 13 '14 at 19:05
2

The way I've read this is that a value object is an object that does not have an identity unto itself and that has nothing to do with its state changing or not changing. This makes the difference between an entity and a value object that an entity has a primary key, whereas a value object does not; it will have a foreign key to the entity it belongs to.

http://lostechies.com/joeocampo/2007/04/23/a-discussion-on-domain-driven-design-value-objects/

I can still change the value object's properties, but it doesn't need to ever be identified independent of it's entity.

|improve this answer
  • I mixed in terminology from relational databases (primary key) as identity as a metaphor, please don't take it to literally – Kevin Jan 8 '14 at 21:32
  • To my understanding at least, even if in code VOs are represented with a mutable type ( thus instances of this type can have their properties modified ), conceptually these VOs are still immutable. Thus, changing a property of an instance representing a particular VO means that now this same instance represents a different VO. In other words, VOs are conceptually always immutable – bckpwrld Jan 8 '14 at 23:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.