4

Knowing that value objects represent a description of the domain, this description can be part of many entities in different bounded contexts. For example the FullName value object, this VO can live in a "book aquisition" context as member of a Customer entity , also it may live in a "book management" context as a member of a BookAuthor entity. Knowing that value objects can be used in different parts of the domain, where should value objects be implemented ? Should they have a special layer/module that every bounded context will be using when needed?

Tudor
  • 1,133
  • 1
  • 12
  • 28
  • Isn't `FullName` a property of the `Customer` or `BookAuthor` entity? I wouldn't consider it a value _object_. A value object is uniquely identified by its value, like `Color.Red`. – Davin Tryon Jun 02 '14 at 15:20
  • @DavinTryon Shouldn't value objects have no identity? But yes you could say that they are identified by their value but don't forget about type , so they are identified by value + type. Because there might be different types of value objects with similar attributes (ex: YearInterval VO and MonthInterval VO they both have days as attribute but different range). Also a FullName{firstName;lastName} is a descriptive property of many domain objects (person, author, customer, tenant, shopOwner etc) from different contexts, so yes it should be treated as a value object. – Tudor Jun 02 '14 at 15:44
  • 1
    @DavinTryon A full name is uniquely identified by its value as well. "David Tryon" is equal to "David Tryon", even if there are distinct persons carrying that name. Expressing a full name as a value object instead of a simple string makes the concept explicit and allows the implementation of additional functionality, e.g. `string LastCommaFirst()` or `string Initials()`. – Dennis Traub Jun 03 '14 at 09:44
  • @DennisTraub Yes, I see your point. I guess you could classify _any_ composite value as a value object. However, this obviously complicates the code base. For me, I would question the use of the value object. As you pointed out a common audit interface could use the full name etc, fair point. BTW, the value "David Tryon" != "Davin Tryon" :-) – Davin Tryon Jun 03 '14 at 10:09

2 Answers2

6

Each bounded context should implement its own value objects (and entities, of course), even if this leads to code duplication.

As a rule of thumb code reuse across context boundaries should be avoided. There may be exceptions to this rule but using common libraries with domain-related content will quickly interfere with the independent evolution of the affected domain models.

Note: Dan Bergh Johnsson delivered a great and worthwhile talk called The Power of Value - Power Use of Value Objects in Domain Driven Design at Øredev in 2011.

Dennis Traub
  • 50,557
  • 7
  • 93
  • 108
  • I agree that code reuse across contexts might harm when the domain is very large and complex . But by not reusing value objects it seems that this concept is useless, you could easly move the logic regarding values/properties inside the entities (simple int/string properties). I feel like value objects are context agnostic mostly. A FullName is a full name in every context (it must have a first and last name allways). I feel that value objects are aspects of the domain as a whole. Shouldn't one leave the properties bound to a context inside that context entity without using a VO ? – Tudor Jun 03 '14 at 14:55
  • VO are not context agnostic, however some of them might be generic enough to represent their concept across specific context boundaries. In that case I'd reuse it, but only if the concept definition stays the same. For ex, a Price should mean the same thing in many contexts. Btw, Entities and VO are unrelated to objects and properties. You can have objects that are neither Entities nor VO. And it really doesn't matter, the only practical value the DDD terms have is when 2 or more developers discuss about technical stuff. But they don't affect the actual modelling. – MikeSW Jun 03 '14 at 18:01
  • @Tudor Objects usually aren't just collections of data, they expose behavior, have roles and different responsibilities. This is true for many value objects as well. A full name certainly consists of first name(s), last name, academic title, salutation, etc in most if not all contexts. But in different contexts it could expose very different behavior. In some for instance it could be able to offer a somewhat anonymized representation of itself. In another context it should be able to expose its data in different languages (i.e. localized salutation and academic degrees, order of names, etc.) – Dennis Traub Jun 04 '14 at 12:16
  • @DennisTraub I'm using ddd with cqrs not to read data but only for state change/ for writes. There are VOs like full name that the behaviour stays the same for many contexts. It's really impossible to attach different behaviour for state change when it comes to many VOs. Yes when it comes to presentation of an object, this may require different design, but visualising an object in a different way by manipulating it's description is not behaviour in my opinion. Behaviour is what an object can do, not how it "looks like". – Tudor Jun 04 '14 at 12:40
  • @MikeSW Yes i found a similar answer by vaughn vernon in a post. He sugest to use a generic model with standard types for some objects/VOs that behave the same in many contexts. – Tudor Jun 04 '14 at 12:41
  • @Tudor Using VOs in a CQRS-based scenario indeed is somewhat different.. On the other hand even in a CQRS write model a VO might expose a representation of its state, if only to allow the surrounding aggregate to enforce its consistency. And what if not all affected bounded contexts use CQRS? (I'd even go as far as to question if a full name would be part of any write model at all.) That said: Yes, in a strict sense state representation should NOT be considered behavior in object orientation as it was meant. – Dennis Traub Jun 04 '14 at 12:52
  • 1
    Certain concepts may exist across multiple domains/bounded contexts that are exactly the same and rarely change. For example we use a currency value object across nearly all of our BCs. Since inception of our company this has never changed. We have a VO library that we share across many of our BCs. It has been beneficial and has not caused any issues. Being practical must come into play here! – bstack Jun 04 '14 at 15:00
  • @bstack Certainly yes. That's why I called it a rule of thumb, not a law, or dogma. – Dennis Traub Jun 04 '14 at 16:01
  • @MikeSW It's hard to say that Vos and entitis are not related to objects. They are objects :) the business concepts need to be modeled in objects. The real business model (if you would put humans to do the job) differes alot from the automated business model (made from objects - oop). Actually, thinking a bit more, VOs are actually a good oo practice, VOs could be just a rule/term for good OO practice. So VO is just a recognition that a developer should use good OO practice. Like i said in an extreme case, one could put everything inside an entity w/o using VOs . – Tudor Jun 05 '14 at 06:43
0

Value Object of domain layer should be in aggregates. but in some cases, VOs are so general as you mentioned. we put those kinds of generic value objects in special module available for all aggregates but we had one bounded context in our project. IMO you can put your Value objects of each bounded context in it's own.

Ehsan
  • 816
  • 9
  • 27