Domain Driven Design is a development methodology, the term have been coined by Eric Evans ¹.

Domain Driven Design (DDD) being a complete development methodology, that means that you can’t learn DDD simply by reading code sample, and a few things are necessary for his success, such as:

• Developers who understand design patterns
• Access to a Domain Expert and close relationship with the client

The domain expert requirement is a big one, you actually need someone from the domain, ie: if you are in the banking industry, you need a banker to have this role, not a developer or an architect who is a self proclaimed domain expert. DDD involve a lot of communication with the domain expert to define the ubiquitous language ² and integrate them in the domain models. To keep using our banking example, a developer who knows absolutely nothing about banking should learn an awful lot about the domain (banking) just by looking at the code for the domain model.

A DDD team will probably be using a bunch of design pattern such as:

• Domain Model
• Service Layer
• ActiveRecord or DataMapper
• LazyLoad
• Repository & Query Object

But the sole fact of using these patterns does not mean you have a DDD team. I can’t find the orignal source, but apparently ³ Eric Evans almost regrets having mentioned these design pattern in the book because they can lead to that false conclusion that DDD is just ‘using some specific design pattern’ when if fact it is so much more and involve discussion and collaboration with clients and domain experts. We can see the same feeling about design patterns and lack of domain expert expressed in the excellent video “7 Reasons Why DDD projects #FAIL” ⁴ by Greg Young.

DDD is not for everybody, if your app is mainly retrieving data from the database to display with some fancy design, DDD would just be adding a layer of complexity on something really simple, ActiveRecord or DataMapper is probably a better solution for your need. Such an example where DDD is overkill, and e-commerce website for Mom & Pop’s shop, as there is little logic, lots or database reading and some cool graphics… But complex subscription plan and pricing and discount model is a good candidate for DDD.

I won’t go deeper into the world of DDD as I have no experience with it and I’m not currently working on any team that can switch to this methodology easily.

I’ll close this part with a great quote from “DDD Step By Step” ⁵

[...] I view Domain Driven Design firstly as a design methodology, secondly as an architectural style, and lastly as some great software patterns.

More Reading

Stack Overflow have some good links to get you started with DDD

http://stackoverflow.com/questions/493068/best-resources-on-the-web-for-learning-domain-driven-design-ddd-in-depth

(my favorite being the InfoQ miniBook, a quick read that give just enough information to get you interested)