After doing DDD (on a very basic level) for sometime now, I now realize that I could benefit with some sort of sum up. Often when I reach this point I quickly realize that many people has tread this paths before and that I’m reinventing the wheel… Well, in that case I do it for me. I like my wheels or at least my way of understanding them…
So here is my take on what the deal with DDD is (i hope that it will change over time but here is how I see it today):
I think first that the whole idea of DDD can be divided into two aspects (actually Jocke pointed me in this way but i like it):
- first code - a bunch of design patterns that help you produce great object-oriented, testable software
- then the implications on the way you can do software projects.
For the code part there is not much to add, or rather not much that could fit here. But what I mean is that to do DDD is “simply” to apply the patterns Domain Model, repository, aggregate, services, factories and more.
It can be quite a challenge to grasp all these patterns and put them into use at once, so I recommend a some reading, that will set your mind into DDD-mode and most of the patterns will fall into place by themselves. Or you can grab hold of an example architecture and build from that.
The other part of the story is the way that setting your brain into DDD-mode will change the way you can be agile in your project. The main idea (as I founded out, and here) is of course to focus on the model and let implementation details such as database integration, technology or even GUI be of secondary importance. Of course you cannot take in the complete universe of your problem at once so doing a small part of it and letting that evolve with time is a recommended approach. See this from Jimmy Nilsson.
This approach lend itself very well to do in the form of for example user stories and TDD. In this way you only need to focus on the part of the model that the user story is about. The next user story might tell us more about the same part of the domain model, but we don’t care now. The tests will assure us that we’re not breaking anything that already works as we progress.
So by doing DDD you automatically get a step-by-step evolving architecture and also a very good way to use an agile approach in the project.
With BDD (a subject I know very little about) you can even go further and get specifications that you verify with tests. But that is out of knowledge.