Value Objects in CQRS - where to use

38
votes

Let's say we have CQRS-inspired architecture, with components such as Commands, Domain Model, Domain Events, Read Model DTOs.
Of course, we can use Value Objects in our Domain Model. My question is, should they also be used in:

  1. Commands
  2. Events
  3. DTOs

I haven't seen any examples where Value Objects (VO) are used in the components mentioned above. Instead, primitive types are used. Maybe it's just the simplistic examples. After all, my understanding of VOs use in DDD is that they act as a glue for the whole application.

My motivation:

Commands.
Let's say user submits a form which contains address fields. We have Address Value Object to represent this concept. When constructing command in the client, we should validate user input anyway, and when it is well-formed, we can create Address object right there and initialize Command with it. I see no need to delegate creation of Address object to command handler.

Domain Events.
Domain Model already operates in terms of Value Objects, so by publishing events with VOs instead of converting them to primitive types, we can avoid some mapping code. I'm pretty sure it's alright to use VOs in this case.

DTOs.
If our query-side DTOs can contain Value Objects, this allows for some more flexibility. E.g., if we have Money object, we can choose whether to display it in EUR or USD, no need to change Read Model.

5
domain-driven-designdtocqrsvalue-objects
After pondering this for a while, my conclusion: having behaviour-rich objects in Events is simply impossible, as they must represent historical data, and we have no way to serialize behaviour today. As for Commands and Read Model DTOs, this might work, and it is still unclear to me if the coupling it introduces is acceptable or not (anyway, this is more about 'should both Domain and Presentation layers reference the same implementation of Money VO' rather than 'should TransferMoneyCommand contain Money VO or MoneyDTO' ). – driushkin
There is a similar discussion going on on the PHPDDD repository. Feel free to join: github.com/webdevilopers/php-ddd/issues/14 – webDEVILopers

5 Answers

27
votes

Ok I've changed my mind. I have been trying to deal with VOs a bunch lately and after watching this http://www.infoq.com/presentations/Value-Objects-Dan-Bergh-Johnsson it clarified a couple of things for me.

Commands and Event are messages (and not objects, objects are data + behavior), in some respects much like DTOs, they communicate data about an event and they themselves encapsulate no behavior.

Value Objects are not like DTOs at all. They are a domain representation and they are, generally speaking, rich on behavior like all other domain representations.

Commands and Events communicate information into and out of the domain respectively, but they themselves do not encapsulate any behavior. From that perspective it seems wrong and a possibly a violation context boundaries to pass VOs inside of them.

To paraphrase Oren (though he was referring to nHibernate and WCF) "Don't send your domain across the wire". http://ayende.com/Blog/archive/2009/05/14/the-stripper-pattern.aspx

If you want to communicate a value object, then I suggest passing the necessary attributes needed to re-construct the VO within them instead.

Original Text (for posterity):

If you are asking if Value Objects can be passed by the domain model to events or passed in by commands, I don't really see a huge problem with the former, though the latter may violate some of the rules of the aggregate root being the "owner" of values.

That said a value object represents concepts like for example a color. You don't have green, you are green or not. There seems to be nothing intrinsically wrong with a command telling you that you are green by passing this.

Reading the chapter from DDD on the Aggregate Root pattern explains Entities and Value Objects quite well and is worth reading over a few times.

5
votes

I say it's a bad idea.

There's a reason we don't do the same with entities - to avoid coupling other parts of the system to the domain (in the wrong places). The same is true for Value Objects, the only difference between value objects and entities is lifetime and ownership - these differences do not affect how we should and should not couple to them.

Imagine that you make an event contain a VO. A change in your domain requires you to change that VO. You've now boxed yourself into a corner where your event is also forced to change, ditto for any Commands or DTO's it's a part of.

This is to be avoided.

Use DTO's and/or primitives. Map them (AutoMapper makes it a 1-line deal).

3
votes

Similar to other answers, in SOA this would break encapsulation of the service as the domain is now leaking out.

0
votes

According to Clean Code your DTOs are data structures (just to add another term), while value objects are objects. The difference that objects can have behavior. Mixing data structures with objects is generally a very bad idea, because it will be hard to maintain the hybrid you get.

I don't feel right to put value objects to DTOs from an architecture perspective as well. The value objects are inside of the domain model while the DTOs you mentioned are defining the interface of the model. We usually build an interface to decouple the outside world from the inside of something. So in the current case we added DTOs to decouple the outside world from the value objects (and other model related stuff). After that adding value objects to the interface is crazy.

So you haven't met this solution yet because it is an anti-pattern.

0
votes

Value Objects are or at least should be immutable. Once instantiated with a value that value will never change throughout the lifetime of the object. Thus, passing VOs as data to DTOs (such as Events) should not be an issue since all you can do with them is get their value. At the most their value in a differing representation such as toString() as opposed to an original getValue() which might return an integer or whatever the value is.