What makes my code DDD (domain-driven design) qualified?

Question

Hi All,

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?

Answer 1

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 it's 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.

Answer 2

DDD isn't really a checklist - it's a methodology.

In addition to Stefans answer, I'd suggest the following (in order of importance):

• Ubiquitous language - Does your code use the same names/terms as the business? Do your Domain Objects use the same names as the business?
• Behaviour - Is most behaviour/logic associated directly with Domain Objects, or do you have a lot of dumb DTOs?
• Bounded Contexts - Have you clearly defined areas of responsibility and Separation of Concerns?
• Aggregates - Have you identified Aggregates based on root objects, and the locking strategies to enforce business invariants?
• Repositories - Is all data access/querying done via Repositories, or do you have SQL code in other classes?
• Domain Services - Do you have Domain Services for business logic that doesn't naturally fit in a Domain Object
• Specifications - Do you have business rules nicely wrapped up in Specifications?
• Query Specifications - Do you have pre-canned queries/filters nicely wrapper up in Query Specifications?

Then there's all the other stuff!

I think most DDD practitioners would want to say:

"I work with Domain Experts to understand their needs, and write systems that (a) match the Businesses terms and Processes, (b) help other Developers understand the business domain, and (c) can flex to accomodate changing business requirements."

Hope that helps!