Recorded at:

Power Use of Value Objects in DDD

Presented by Dan Bergh Johnsson on Nov 20, 2009

Community

Architecture

Topics

Domain-Driven Design

Tags

QCon London 2009 ,

QCon

The next QCon is in London Mar 10-12, Join us!

1. Back to top

   Excellent presentation.

   Nov 21, 2009 7:27 AM by Raj Moodaley

   Good example of how value objects can simplify the code and extend the domain language

   Reply

2. Back to top

   Very Good

   Nov 21, 2009 11:36 AM by Chris Gardner

   Highly recommended. Dan illustrated that code that might appear wholly in an entity or DTO can more appropriately be moved to a Value Object. Something that I inferred from the presentation is that a DDD style Policy or Specification would also benefit from operating on a number of smart Value Objects.

   Reply

3. Back to top

   Very Good Presentation

   Nov 21, 2009 4:33 PM by Ashok Guduru

   A very good example showing the difference between DTO and VO for the people confusing between them.
   
   IMO a real-world business application should never use the primitive data types on domain objects. There will always be a value object perceivable for every single element of business object's data.
   
   Thanks.

   Reply

4. Back to top

   Great!

   Nov 28, 2009 10:27 AM by Justin Forder

   Very clear presentation, immediately useful, requires no previous exposure to DDD.

   Reply

5. Back to top

   Where to draw the line?

   Dec 2, 2009 12:30 AM by Pedro Dias

   I'm curious to learn where you draw the line - Field Identifiers, such as primary keys on typical record objects - should these be value objects offering a range of validation features? (a database Id cannot be zero or negative).
   
   Conceptually, one is still speaking about "RecordId" as an abstract consept, thus, according to your line of thought, it warrants the use of a RecordId class, however, this is extremely hard to sell to a developer who could care less about order.
   
   Value objects also have a dark side - they complicate the use of ORMs such as hibernate and EF.

   Reply

6. Back to top

   Re: Where to draw the line?

   Dec 5, 2009 5:57 PM by Dan Bergh Johnsson

   I'm curious to learn where you draw the line - Field Identifiers, such as primary keys on typical record objects - should these be value objects offering a range of validation features? (a database Id cannot be zero or negative).

   
   
   I am very pragmatic about it. Does it smooth out discussions with product owners, dbas, gui designers, users or other stakeholders? Or, does it clarify code, leading to less repetition (DRY violations), bugs, or awkward code? In any of those cases: Yes. If none of those benefits, and no other: No, spend your time and energy somewhere else where you have a better payback for your efforts.
   
   

   Conceptually, one is still speaking about "RecordId" as an abstract consept, thus, according to your line of thought, it warrants the use of a RecordId class,

   
   
   In many cases technical constructs like "RecordId" or "Customer Number" take on a life of their own and become part of what stakeholders need to be conceptually aware of. It sounds like that in your example. Litmus test: check the parameters of the methods in the service layer API (called by presentation). If it is in there, an explicit value object class is probably a good idea.
   
   

   however, this is extremely hard to sell to a developer who could care less about order.

   
   
   Did not quite understand ... Do you mean "order" = "ordering/sorting" or "order" = "request for goods or similar"?
   
   And in what way is it a "hard sell" to developers? Are they not interested in "fluffy domain stuff"?
   
   

   Value objects also have a dark side - they complicate the use of ORMs such as hibernate and EF.

   
   
   I would phrase that the other way around. ORMs have a dark side - they complicate the use of value objects; limiting your design power. :)
   
   But seriously: that trouble is historically an undebatable fact, but in "modern" versions e g JPA 2.0 it has become *a lot* better.
   
   Dan Bergh Johnsson

   Reply

• Older >