InfoQ Homepage Presentations Power Use of Value Objects in DDD
Power Use of Value Objects in DDD
Summary
Dan Bergh Johnsson refreshes the listeners’ memory on using value objects showing by example how their good use can revolutionize a program’s architecture, simplifying it, making it more readable and testable, in a word, better.
Bio
Dan Bergh Johnsson has been teaching at the Computing Science department at Uppsala University, Sweden, and has been using unit testing, DDD, and Agile for his consulting activity. He is also a speaker at national and international conferences such as Colorado Software Summit, ExpertZone, SoftDev, and JavaZone.
About the conference
QCon is a conference that is organized by the community, for the community.The result is a high quality conference experience where a tremendous amount of attention and investment has gone into having the best content on the most important topics presented by the leaders in our community. QCon is designed with the technical depth and enterprise focus of interest to technical team leads, architects, and project managers.
Community comments
Excellent presentation.
by Raj Moodaley,
Very Good
by Chris Gardner,
Very Good Presentation
by Ashok Guduru,
Great!
by Justin Forder,
Where to draw the line?
by Pedro Dias,
Re: Where to draw the line?
by Dan Bergh Johnsson,
The Elements of Simple Design to the rescue
by J. B. Rainsberger,
What constitutes a valid text representation of a PhoneNumber depends...
by J. B. Rainsberger,
Good presentation
by Oyku Gencay,
Informative, still have questions about persistence and Spring DI
by Alexander Yin Yang,
Excellent presentation.
by Raj Moodaley,
Your message is awaiting moderation. Thank you for participating in the discussion.
Good example of how value objects can simplify the code and extend the domain language
Very Good
by Chris Gardner,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
Very Good Presentation
by Ashok Guduru,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
Great!
by Justin Forder,
Your message is awaiting moderation. Thank you for participating in the discussion.
Very clear presentation, immediately useful, requires no previous exposure to DDD.
Where to draw the line?
by Pedro Dias,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
Re: Where to draw the line?
by Dan Bergh Johnsson,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
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.
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"?
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
The Elements of Simple Design to the rescue
by J. B. Rainsberger,
Your message is awaiting moderation. Thank you for participating in the discussion.
Yet another way that I use the Elements of Simple Design in my work. Writing tests exposes the scattered copies of the same algorithms by duplication irrelevant details in the tests [ bit.ly/6wXgmS ]. Of course, the scattered copies of the algorithms are, themselves, duplicated. In addition, names like justnumbers(), while structurally accurate, bear improving, and when that code moves onto PhoneNumber, it becomes clearer to rename it to isValid().
I really like the idea of PhoneNumber becoming part of a glossary for what /we/ mean by "phone number" on this project right now.
What constitutes a valid text representation of a PhoneNumber depends...
by J. B. Rainsberger,
Your message is awaiting moderation. Thank you for participating in the discussion.
...on the app, in particular. This makes moving isValidPhoneNumber() onto PhoneNumber a little strange to me. It gives PhoneNumber knowledge about the application. Perhaps my application allows the format "+1 888 655-2724" or requires only "18886552724". I don't know that that's a domain-level decision.
Still, wherever the validation rule resides, I hope to find it only in one place. :)
Good presentation
by Oyku Gencay,
Your message is awaiting moderation. Thank you for participating in the discussion.
A good introduction on why and how to refactor.
Informative, still have questions about persistence and Spring DI
by Alexander Yin Yang,
Your message is awaiting moderation. Thank you for participating in the discussion.
First of all, thanks for interesting content. I'm curious about cases when there are many logic methods, that require receiving data from DB for calculations. How can I effectively use Value Object pattern in that case?
Also, about error handling. What if I need different behaviour for incorrect input. Let's say, in one case I need to accumulate errors from all of form fields before respond with error to client instead of instantly falling? Exceptions are seemed to be inappropriate here