gervais.b
gervais.b

Reputation: 2347

Domain Driven Design; Can ValueObject contains invariants or specifications?

I'm starting to play with Domain Driven Design and have a question about ValueObjects :

Can they contains invariants or other specifications ?

Consider an immutable ValueObject :

ValueObject (

  prop integer: Int
  prop string: String

  // Value and copy constructor

  // Observers for integer and string

  // Equality methods on integer and string value

)

Can I add some invariants such that integer > 0 & < 42. Or do they have to be simple transfer without any logic ?

I hope they can but need a confirmation.

Upvotes: 3

Views: 1240

Answers (2)

alanager
alanager

Reputation: 31

Value objects should handle the invariants for the data that they encapsulate, or at least as much of it as they can. I tend to do the following, which is actually similar to entities except for the immutable bit:

  • Constructors should make sure it is created in a valid state
  • The VO's state is encapsulated, and all changes to it are done through controlled methods/etc
  • Because value objects are immutable, method changes return a new value object rather than updating the existing state

Having the value objects own their own business logic really helps clean up the code in the entities that use these value objects. This can become a problem with big aggregates\entities, so look for opportunities to pull this behavior out into value objects.

It also makes unit testing lots of edge cases MUCH easier, as you are testing the value object on its own.

Your entity may need to do validation across multiple value objects before decides a change CAN happen, but then the value object is responsible for the change itself.

Upvotes: 2

MikeSW
MikeSW

Reputation: 16368

A value object (VO) encapsulates a value and its business requirements . This is its purpose: to model a business concept (with its constraints) which happens to be a simple (not always single) value.

A VO is not a Data transfer object (DTO) precisely because it defines a business concept that is valid only in the containing bounded context, while a DTO is meant to cross boundaries.

Upvotes: 5

Related Questions