Dan started the talk by outlining the goal for the presentation which was to 'show how power use of value objects can radically change design and code, hopefully for the better'. A lot of the presentation was spent refactoring code written without value objects into shape.

We started out with a brief description of what value objects are not which I found quite amusing. To summarise,they are not DTOS, not Java beans and not objects with public fields. The aim with value objects is to swallow computational complexity from our entities. Creating what Dan termed 'compound value objects' provides a way to do this. The benefits of doing this are reduced complexity in entities and code which is more extensible, more testable and has less concurrency issues.

I found myself quite intrigued as to how you would be able to spot an opportunity in your code to introduce a value object and almost as soon as I wrote down the question Dan covered it! Some opportunities include strings with format limitations, integers with limitations or arguments/results in service methods. The example used was a phone number which was being passed all over the place as a string - refactoring this allowed the code to become explicit - before the concept existed but it was never properly spelled out - and it pulled all the functionality into one place.

Dan’s term for this was 'data as centres of gravity' - once you have the value object anything related to that data will be drawn towards the object until you have a very useful reusable component. He pointed out that 'your API has 10-30 seconds to direct a programmer to the right spot before they implement it [the functionality] themselves'. I think this was a fantastic reason for encouraging us to name these objects well as we pretty much only have the amount of time it takes to hit 'Ctrl-N' in IntelliJ, for example, and to type in a potential class name.

Another interesting point which was being discussed on twitter as the presentation was going on was whether we should be going to our domain expert after discovering these value objects and asking them whether these objects made sense to them. Dan said that this is indeed the best way to go about it. I have to say that what struck me the most across all the presentations was the massive emphasis on getting the domain expert involved all the time.

Seemingly randomly Dan pointed out an approach called composite oriented programming which is all about using DDD terminology but inside a framework to drive development. I’ve only had a brief look at the website so I’m not sure if it’s anything worth shouting about.

In the second half of the session compound value objects were introduced - these basically encapsulate other value objects to come up with even more explicitly named objects. The examples in the slides are very useful for understanding the ideas here so I’d recommend having a look from slide 44 onwards. The underlying idea is to encapsulate multi object behaviour and context and make implicit context explicit. This idea is certainly one that is new to me so I’m going to be looking at our code base to see if there’s an opportunity to introduce the ideas I learnt in this talk.

To close Dan rounded up the benefits we get from introducing value objects into our code - context aware client code, smart services and a library with an API.