Implementing Domain-Driven Design by Vaughn Vernon
My rating: 4 of 5 stars
I think this is a great book in terms of the ideas it promotes, but for me somewhat flawed.
It’s billed as a companion to Domain-Driven Design: Tackling Complexity in the Heart of Software and as such is less abstract and works through some case studies to get to the meat of what that the original DDD book only hinted at and actually went round and round a lot.
For me it harks back to a lot of things I have recently read and done, in particular the design process for good (for some definition of the word) object-oriented software, as Practical Object-Oriented Design in Ruby: An Agile Primer covers really well. Sandi talks about OO being all about the messages, and you end up with well put together clusters of objects if you start from there.
DDD comes at the problem from a different direction, instead starting out at a higher level of abstraction in the problem domain, rather than creating objects and seeing how they work together. It has some tools for uncovering what the business wants. It starts by looking for a ubiquitous language and making sure that the development and testing silos are speaking the same language as the business.
Of course, it’s more complicated than this. Vernon gives the example of a book publisher. The people commissioning a book need different language to describe setting up their relationship with an author and paying them, the people creating the book and illustrating it again have different needs, and distributing and stocking the final physical product is different again. So, if you were trying to create some kind of master book object that met all of these needs you may well end up with conflicting terms, and indeed needs expressed by those terms.
To get round this you break your problem space into bounded contexts, and these become functional areas which each have the own ubiquitous language. This gets around the weird mashing together of functionality that quite often makes large systems a complete pain to maintain. Each area manages its own needs and translates, as and when required, if it needs to talk to another. I believe that a pretty reasonable SOA architecture will fall out of this in the end.
I think I’ve understood this process after a hundred pages or so, but I don’t want to read any more of the book. I had the same problem with the original DDD book as well. The core concepts are pure gold, but the presentation is extremely repetitive, wordy and really hard to read for useful content. Both books needed more pictures and a catalogue of the concepts, organised rather like Martin Fowler’s Patterns of Enterprise Application Architecture – with about 100 pages of well-written and illustrated chat with the remainder of the book taken up with a list of the patterns in detail once you know how to use them. In fact, both books need a damn good edit.
The other thing that I find really annoying is things like bounded context, once introduced, are always capitalised Bounded Context. Maybe it’s just me, but the constant capitalisation of a concept really breaks the text up and interrupts the flow. The original DDD book does this as well. This capitalising thing is a disease caught from an old-fashioned style of writing, common to people who read the King James Bible, which was written at a time when you would capitalise nouns. Myself, I use italics when I introduce a concept and then either abbreviate it to, say, BC, or just use it as normal. This capitalisation reads like the old pompous religious tracts handed out by slightly demented people going door to door when I was a kid, and I didn’t like it then either.
So I would like a list of all of the Ideas Expressed With Capitalisation and how to use them, and about half the amount of text without all the waffle. I gave up because I got the concepts and the rest of the signal to noise was too low.
The cartoons of the cowboys make no sense to me either, and there was a weirdly old-fashioned feel to the one offering your stakeholder a cup of coffee to talk to them. You could probably put each chapter into about three paragraphs and not lose a lot of information.
So, I gave the book four stars because the ideas are incredibly useful, but be prepared to struggle with keeping awake between the useful nuggets.
Incidentally, if you want Sandi’s book, please buy it from her site.