The quick skinny on Domain Driven Design (DDD)

This post is another one of my quick cheat sheets to an alt-coder buzz phrase being bandied about, in this case Domain Driven Design. After reading this you should be able to understand what the A-Listers are talking about when they post about how they emphasize DDD to their teams along with TDD, IoC, and F73-persistence (Ok, I just made that last one up).

First off lets clear up a quick point. The ‘Domain’ in Domain Driven Design refers to a domain of expertise or business such as banking, aerospace, llama farming, etc. It does not in this case refer to any sort of technical-system use of the word domain like a Microsoft network domain or any other such imaginary nonsense.

For comparison, here is a quick bullet list of typical tighty-whitey, non-DDD project:

• Some non-social-liability business analyst or project manager (PM) meets with business guys / gals to get the specs.

• Said PM learns from business people about the business, figures out how their business need might translate into an app or website or whatever.

• PM talks to technical lead of software team, describes what the desired inputs, outputs, and business rules of the future system are.

• Dev team architects and jams out code to meet those ins-and-outs requirements based upon their best coding practices for making the calculations calculate and the reports report and wraps it up in an interface mocked up by emo Apple dude or chick.

Ok, with that in mind then, here is the fundamental DDD gist:

Domain Driven Design is a OOP software design which models itself on the way a given business domain works in the real business world. The classes, objects, naming of things, code mechanisms, etc are designed as best as possible to match the way the business that the software is being written for really functions. Rather than an end product that just takes the requisite ins and produces the requisite outs via developers coding whatever formulas and utilities they can come up with to satisfy the requirements, you strive for a product that under the code hood, actually *works* the way that the real domain does.

The DDD Process:

DDD attempts to level the information playing field, mixing the actual developers with the board room domain experts so that everyone speaks about business concepts in a shared vocabulary. While these colliding worlds may be shocking on a number of fashion, hygienic, and social levels, it is crucial to the process.

These real developers work with the business domain folks to determine how the domain works, modeling out a proposed system using a more generic UML-like workflow diagram that both the developers and business folks can understand. This visual model expresses the way the domain entities (customers, factories, widgets) and business rules work in a way that is compatible with turning into real code.

When it comes to hacking up the actual code, classes and objects are named according to the vocabulary of the domain and try to interact with each other in a way that as close as possible that reflects the way the domain works. This type of scenario lends itself to certain types of OOP coding practices such as services for business rules, factory patterns for object creation, modules for delineating big like sections of a domain (say shipping vs accounting) and loose coupling. The domain layer shouldn’t care about the UI above or the DB below.

Ok, now that you know the basics of Domain Driven Design, don’t overestimate the value of referring to it exclusively as DDD with an air of sophisticated arrogance. This is very useful for intimidating the buzzword-weak who will be too emasculated to publicly ask what it means thereby reinforcing your technical bad-assitude. Forget winning friends, influencing people is where its at!

Linkification:

JP BoodHoo - DDD proponent

Not terribly clear ‘official’ DDD site

Free 100 page-ish ebook ‘Domain Driven Design Quickly‘