Domain Driven Design
Right away you can incorporate the language of the code into your discussions with experts. In natural language, it’s equivalent to going from saying “well, to store this we’ll add an entry that tells us that a category belongs to a user and the user can have many news categories to tell us what they want to be told about” to saying “when someone wants to get News from our various Categories, we
create them a Subscription”.
Ok, maybe I’m exaggerating or overstating it a bit, but that’s the heart of the matter – language and communication. At the root of it is a focus on writing code for humans rather than machines. Coding in a way that can maximise the benefit you get from interacting with the domain experts.
Unfortunately, I hadn’t come across Evans’ excellent book Domain Driven Design at my last place, otherwise I think I would’ve made some different decisions and definitely framed my work better. However, on my current Java project with ThoughtWorks we have made efforts to focus peoples minds on the domain and to try and leverage the domain experts’ understanding as best as possible, and synchronise our code with it.
Last week I was pairing with a client developer and we performed a little model refactoring, naming concepts and relationships consistently with the notes and spontaneous diagram drawing we’d done during some quick domain model/discussion meetings.
The refactoring went pretty well (despite it throwing up some interesting issues with the introduction of a `Money` value object and resulting IBM `BigDecimal` and trying to store the aggregate within our Hibernate mapping).
We tried originally to use our own `CompositeUserType` but this turned out to be more work than it was worth and we took a hit on the DRYness and used Hibernate’s component mapping which actually turned out pretty good. The result is that we’ll have to define entries for our `Money` in each class that contains a `Money` value, but the value is it also stores the value inside the containing class which is good.
Ultimately, I’m more mindful now of how meaning is conveyed through the code and how it’s possible to incorporate natural domain language into the naming of concepts, and the introduction of new objects and classes where there’s value in the communicativeness. Of course, it seems rather common sensical but as always it’s easy to see how you just pass the obvious by (or at least I certainly have been vulnerable to it in the past).
It’s important that this kind of process is continual and evolutionary. Refactor as you go based on the knowledge you have. As the domain model changes, or your understanding deepens – change the code to follow suit. It’s amazing how much easier the resulting code is to talk about and build on.
Anything that makes it easy to write code in a manner such as this gets my vote. I’m looking forward to really learning Ruby and finding out how I can wrap it in such a way to write better code. After all, Rails provides some pretty nice language-looking bits for handling database mapping, web application handling etc. DSLs anyone? :)
