Consider the following class:<\/p>\n
class Person {\n public string FirstName;\n public string LastName;\n public string Initials;\n public string Address;\n public string Street;\n public int HouseNumber;\n public string Telephone;\n public string Mobile;\n public string Email;\n public string WorkAddress;\n public string WorkStreet;\n public string WorkHouseNumber;\n public DateTime ActiveStart;\n public DateTime? ActiveEnd;\n \/\/ ... and many more?\n}\n<\/code><\/pre>\nAnd how beautiful it could\u2019ve been:<\/p>\n
class Person {\n \/\/ The first version was quite obfuscated, while in this version it's\n \/\/ quite obvious what's in it by merely glancing at the declaration.\n public Name Name;\n public Contact Contact;\n public Address HomeAddress;\n public Address WorkAddress;\n public DateRange Active;\n}\n\nclass Name {\n \/\/ Please don't repeat the Name for each property here\n \/\/ Considering the current class, we know the context!\n public string First;\n public string Last;\n public string Initials;\n}\n<\/code><\/pre>\nAdvantages<\/h1>\nFor the IDE<\/h4>\n
Instead of a long list of properties that may be difficult to navigate in your IDE, where it is difficult to spot that one property you need, one could instead split it up in things that logically belong together to keep intellisense small and focused.
Keep data that belongs together – together!<\/p>\n
For the UI<\/h4>\n
Such stuff is usually displayed together. All the way down to the frontend, passing an Address<\/code> to an AddressComponent<\/code> is very preferable over passing those properties in separately.<\/p>\nFor Expressiveness<\/h4>\n
Without our precious ValueObject<\/code>, we would end up creating all sorts of helper classes for often sought after functionality, all scattered around the codebase, some perhaps getting duplicated by different programmers or even for different UserStories.<\/p>\nSome of these helper methods would be much better off being members of a ValueObject<\/code> instead. We get better IDE discoverability and rather than having to pass some or all properties of an entity into an algorithm, we invoke a well-named method on the ValueObject in true TellDontAsk<\/a> style.<\/p>\nAnd isn\u2019t that what Object Oriented Design is all about? \ud83d\ude07<\/p>\n
Recognition<\/h1>\n
If you look, ValueObject<\/code> opportunities will present themselves.<\/p>\nTechnical ValueObjects<\/h2>\n
Classes are very technical in nature and so there\u2019ll be purely technical candidates like, for example, a (still?) popular one:
CreatedOn + CreatedBy<\/code> and UpdatedOn + UpdatedBy<\/code>.
Why clutter (all) your entities with 4 superfluous properties if you can hide them behind a single Audit<\/code> ValueObject?<\/p>\nDomain ValueObjects<\/h2>\n
It is the ValueObjects<\/code> derived from the Business Domain that often offer the most value however. Helper functions for a DateRange<\/code> only go as long as a IsIn(DateTime)<\/code>. For Domain ValueObjects, this can be whatever rabbit Marketing pulls out of their hat depending on the current lunar phase, so the possibilities are endless!<\/p>\nNot Invented Here Syndrome<\/h3>\n
I never thought I\u2019d ever say this: Do not use a package. Yes, there is that well-known and fully-fledged DateRange<\/code> package out there. 80% of its features are probably not useful for your problem domain though. Again you get a long list of methods that basically clutter your IDE. Super handy features that are applicable only in your domain will most likely not be available, as your business probably has very particular requirements.<\/p>\nBusiness Domain Example<\/h3>\n\/\/ A domain where we work with measured stuff\nclass MeasurementResults {\n public decimal Value1;\n public int Value1Precision;\n public decimal Value2;\n public int Value2Precision;\n public decimal Value3;\n public int Value3Precision;\n}\n\n\/\/ Could be turned into\nclass MeasurementResults {\n public Measurement Result1;\n public Measurement Result2;\n public Measurement Result3;\n}\n\nclass Measurement {\n public decimal Value;\n public int Precision;\n}\n<\/code><\/pre>\nRandom Thoughts<\/h1>\nThe True Enemy?<\/h4>\n
Well I guess that missing ValueObjects<\/code> are often an unfortunate side-effect of using a relational database. Your SQL database simply likes things flat. Your ORM probably has something like Custom Types (Hibernate), Complex Types (EF) or Owned Entities (EF Core). If you use an ORM it can probably do the ValueObject creation for you.<\/p>\nDerive, Don\u2019t Store<\/h4>\n
If you can calculate something from existing state, do so. Once stored separately, it will, at some point be out of sync, I guarantee it.<\/p>\n
class Person {\n public string FirstName;\n public string LastName;\n\n \/\/ This simply does not get out of sync\n \/\/ Otherwise each day is trying to remember if the\n \/\/ FullName starts or ends with the FirstName\n \/\/ +You have less state to manage, so hurray!\n public string FullName => $\"{FirstName} {LastName}\";\n}\n<\/code><\/pre>\nConclusions<\/h1>\n
Not creating a value object for coherent pairs of value types is a missed opportunity? \ud83d\ude02<\/p>\n
Extras<\/h1>\n
Other interesting reads<\/b><\/p>\n\n- Patterns of Enterprise Application Architecture – Martin Fowler<\/a><\/li>\n
- EF Core Owned Entities<\/a><\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
ValueObjects<\/h1>\n
A ramble against objects containing DateStart<\/code> & DateEnd<\/code> pairs of properties.<\/p>\nSome of their equally evil relatives:<\/p>\n