Since when, recently, some of my projects grew in a significant way in terms of code and complexity, I started to study and apply domain driven design methodologies to them. I never used DDD before and, honestly, I think that a developer cannot understand and appreciate its value until he/she really needs it. DDD is not about RAD, quick and dirty code or speed away programming, so it's not suitable for project with a less than 6 months development time (like the majority of commissioned websites/webapps). Instead, DDD drives your focus on business modeling and entities, responsibility separation, very loose coupling, events and...value objects.
a value object is a small object that represents a simple entity whose equality isn't based on identity: i.e. two value objects are equal when they have the same value, not necessarily being the same object.
Following this definition, we can have tens of value object classes in our projects: things like money, currencies, countries, URLs, personal data, addresses, emails, etc. can all be suitable value objects. But pay attention, for these kind of objects could be entities too; it depends from the role they have in your project (eg: if you are building an URL shortener, probably your URLs will have to be handled as unique entities, not as value objects). Well, as I mainly deal with PHP and, when talking about frameworks, Symfony, I started to search for a common library of PHP value objects, finding very soon that there wasn't any. So I told myself: "why don't I build it for me and the community?" and that's what I have done: I created ValueObjects, a PHP 5.3+ library/collection of classes aimed to help developers with domain driven development and the use of immutable objects. It currently features:
- date and time components,
- numbers and strings,
- data structures and collections,
- UUIDs,
- personal data,
- money and currencies,
- geographic data,
- internet related data.
The code is 100% tested and as much standard compliant as possible. I tried to not to reinvent the wheel when a library was already there, so I wrapped things instead to hide the underlying code and make developers deal with ValueObjects only. Every value object class must implement a ValueObjectInterface that guarantees the interoperability between two value objects and allows to bypass the PHP weak typing nature. I built it with a certain strictness in mind and that has mainly meant solid (and sometimes quite long) constructors, but this is generally not a problem since every value object class has to implement the static fromNative() method, which allows creating a value object with only native PHP type parameters as arguments. Some friends of mine argued that you should not have a static method signature in an interface, but I think it's ok beacause we are not talking about JAVA here; PHP 5.3+ has a feature called late static bindings which gives a lot of sense to the whole thing. At the time of writing, the current version of ValueObjects is v1.1, so we are expecting great improvements, more classes and namespaces, to* methods in existing classes, maybe serialization and who knows what else. We have a lot of work to do, so every little contribution will be really appreciated; remember: open source is a give/receive concept, let's try to stick it in our mind. Oh, and ValueObjects is released under MIT license, so everyone is really free to use it.