Over the years since finding out about Domain-Driven Design I went through several iterations of grokking it. I’ve also seen other people completely miss the point of “tackling the complexity at the heart”, for example:
I see others going through the same mistakes:
- I’ve dismissed it as nothing but rehashing of OOD principles
- I’ve overdone “IDs are the impedance artifacts, an instance reference is my ID”
- I’ve overdone “everything is an object therefore every class will manage its own behavior”
- I’ve modeled my entities and called it my domain model
I think Evan’s book is partly to blame, the man just wasn’t a writer. Partially, the reason is that what we seek is like Plato’s cave shadows – we may be able to glean a shape of the ultimate form, but it’s only an approximation of the real thing, lacking the detail.
Here’s my current understanding:
- It’s the principles!
We use patterns and principles in our solutions all the time. OOD is
great, but it istoo abstract to be of any value by itself. SOLID is a good starting set, but it doesn’t go into domain modelling. There are lots of other principles that are suitable in one case or another. DDD is just like that, it’s a way to capture desired characteristics of your problem domain in your code. Bringing any kind of dependency, especially a large framework into the domain model deserves a frown. The focus of the modelling, the principles applied, will come at a cost and will be wasted if something is sacrificed for a framework.
- It’s about the code!
We have the models everywhere, some of them are for communicating to the database, some – to communicate to/from external services and some are to talk to people. DDD is about the code at the core of the problem you are working to solve. There maybe a need for a different model for each of the purposes. In CQRS, for example, you are expected to have two separate models within the same app!
- It’s about modelling the behavior!
Which leads me to the ultimate purpose of the domain modelling: capturing the behavior as close to the way business treats it as possible. Have you heard about coding dojos where you have to try and solve a problem w/o ever using the setters? Well, it’s kinda like that, only with a real purpose. The immutability, for example, is of paramount importance when modelling the domain, because that’s one of the few ways to express the meaning and the intent about particular interaction.
- It’s about testability!
Presumably, there’s a significant cost attached to a model that permits a wrong behavior. Keep the model small, abstract and inject all the infrastructure. We shouldn’t need a complex setup to test a theory or modify a behavior and we should test it continuously. The model and the Behavior-Driven tests is our documentation, it’s for the coder to capture and to understand the requirements.