I’m new to DDD and am thinking about using this design technique in my project.
However, what strikes me about DDD is that how basic the idea is. Unlike other design techniques such as MVC and TDD, it doesn’t seems to contain any ground breaking ideas.
For example, I’m sure some of you will have the same feeling that the idea of root aggregates and repositories are nothing new because when you are was writing MVC web applications you have to have one single master object (i.e. the root aggregate) that contain other minor objects (i.e. value objects and entities) in the model layer in order to send data to a strongly typed view.
To me, the only new idea in DDD is probably the
- “Smart” entities (i.e. you are supposed to have business rules on root aggregates)
- Separation between value object, root aggregate and entities.
Can anyone tell me if I have missed out anything here?
If that’s all there is to DDD, if I update one of my existing MVC application with the above 2 new ideas, can I claim it’s an TDD, MVC and DDD applcation?
The short answer is that it’s not what your code looks like that qualifies it as a DDD project, it’s how you arrived at that code. Now for the long version…
You’re absolutely right that there isn’t anything very revolutionary about the DDD coding practices, but you seem to be a little off target with your question. A common mistake that many developers make with DDD is to focus too much on the coding practices while ignoring some of the more fundamental concepts of DDD. At its very core, DDD is a practice of iteratively developing a model with close collaboration between developers and domain experts. You can code up all the services, entities and value objects you want, but if you aren’t involving domain experts in the process, or aren’t improving the model over iterations, then frankly, you aren’t practicing DDD. Even from a coding perspective, many consider the concepts of aggregate roots, bounded contexts and anti-corruption layers to be more valuable tools than the basic patterns.
You are not alone in how you are perceiving DDD. I find that nearly all developers go through a stage of DDD where they’re trying to implement sample apps using entities, value objects and services while ignoring all the other practices that are fundamental to DDD. DDD is a process designed to handle complex business logic, so judging its merits on a sample app developed over a weekend does not expose you to the best that DDD has to offer. I urge you to continue to look deeper into DDD as I have found it to be an indespensible tool, but never forget that it is much more than a pattern language.