Why Domain Driven Design (DDD) is so great

This article aims to describe why I think that DDD aids you tremendously in creating robust and flexible applications.

Today, we got several cool frameworks and libraries that we can use. ORMs, WCF, ServiceStack, SignalR, WebApi, IoC, etc. Just thinking of all can make any serious developer go crazy with joy.

All those tools are so great that we almost can’t wait to use them. Here is a typical conversation with a customer:

Customer: I want to create a forum.
You: Oohh ohh, wait! Yeah. I could use Sharepoint. No no. It’s so bloated and slow. oh oh! I got it. wait! SignalR+WebApi and KnockoutJS. So cool! Let’s do that!
Customer: But but. We just need a basic forum.
You: Shut it! Me wanna do SignalR.

And so on. My point is that it’s so easy to forget that we should focus on solving a problem for the customer and not on which technology we should use.

The Role of the Database

A couple of years ago, we said that we developed database driven applications. Erhm. Maybe a bit more than a couple of years ago, I’m getting old. It was the sh*t. If you said to a DBA that you have normalized the DB according to 3NF, he would probably have gotten an orgasm. Today, the whole look of applications as data driven has gotten so widely spread that most applications are today modeled according to the database model and its relations.

The problem with that is that the database forces you to couple your application thanks to all DB relations. It also forces you to model the business layer after the DB model. Especially today if you are using an OR/M.

Database centric applications usually lead to CRUD influenced UIs. That is that you show a big fat screen saying “Go ahead and edit the fields you want. I trust that you have full knowledge of which combinations of changes are valid given the current state of the object“. That’s also a huge problem. Business rules are hard to test since it’s the user that enforces them. It will undoubtedly lead to that you have to go into the database and fix things: “Hey, it’s me the customer. Order XX will have the field Y set to Z. That shouldn’t be possible, can you fix that?”. Those kind of bugs are very hard to locate and therefore fix.

Enter DDD

Domain driven design is all about understanding the problem that the customer is trying to solve. During the initial phase, you don’t even think about architecture or programming. Your prime goal is to understand the business, all terms that customer uses and how he models the domain. The customer is in fact the architect. He might not draw everything, but he guides you and tell you how everything should be modeled.

So what you do is sit down with the customer and discuss each business case. You listen to him and draw something which the customer can understand (read: NO UML). Then you use all of those sketches and notes to build the model = code.

Coding

In DDD, you shouldn’t care about persistence, UIs or anything else. You just code vanilla classes which represents the model that the customer described. And since you just have POCOs, it’s incredibly easy to test everything. I highly recommend that you try to use a TDD inspired approach together with DDD.

In DDD, every class in the model should always be in a consistent state (i.e. being valid). That means that you’ll have no (or a very few) public setters in your classes. Instead, you have methods in each class that represents an action that the customer described. If one or more classes (entities) are involved in an action, you’ll create a new class which coordinates the work for both the entities (that class is called a service). Read this if you would like to know more about how private setters affect your application.

Using methods also means that we can’t have CRUD UIs but instead have to code task based UIs. It’s hard when you come from CRUD type of applications, but the task based UI tends to become a lot less cluttered when you get used to coding them.

Finally, you have a nice domain model where all business rules are encapsulated in your classes and hopefully tested with unit tests. The likelihood of bugs like the ones I described for CRUD applications are a lot less.

The Event

Each time something happens (something that the the customer described) in a DDD application, there is an event generated. These events allow you to create a more loosely coupled application.

For instance, when a new user registered an UserRegistered event is generated. It can be subscribed to by a NotifyAdminOfNewUser handler or a SendAnWelcomeEmail handler. Or both. The point is that any part of the system can handle any event. You can even create a module/plugin based application where the plugins handle each others' events. How cool, isn’t that?

Persistence

Most people who have a hard time with DDD have it because they start at the wrong end. They start with the database and then try to fit the domain model according to the db model. That’s the wrong approach (which there of course are solutions for, but that’s out of the scope of this article).

So now you got a solid domain model that would kick a CRUD butt at any time. It’s time to think about persistence. We model our database after domain model. And this time, the relations in the database aren't that important since the database is just storage now. The database is driven by the domain model. Changes in the domain model are persisted to the database with the help of repositories. It’s the repositories job to make sure that there is no stray data in the database. That’s also easy to test using integration test and just push data through the repositories.

This new point of view also allows us to separate the data model into several data sources if we would like (since the data is decoupled in your domain model). We do not have to use one database normalized to 3NF. We can use one big denormalized database (disk space is so expensive, isn’t it?) or even web services in our repositories.

The UI

Now that we got some data and a domain model, it’s time to start creating the UI. Again, we model it after the domain model. Since it’s dictated after all methods that we got in your domain model, it’s quite easy to know how we should structure it.

Outsourcing?

When you’ve modeled the domain model, it’s fully possible to let others take care of the persistence and the UI. Just send them the domain model. In fact, you could even let two different teams take care of it. One that builds and optimizes the data layer (caching, db, etc.), and one that builds the UI.

Let the original team (the domain experts) continue with the next project (or iteration if you’re agile).

Conclusion

That’s why I love DDD.