Nevermind Domain-Driven Design

Over the past years I’ve held many workshops on Domain-Driven Design. We had more than one hundred people on those sessions, and feedback was often pretty good. After last year's sessions, though, I told my business partner that this was my last time running those.

I think that Domain-Driven Design is one of the most important mainstream technical books published this decade. I did enjoy a lot the activities we performed during the workshops and also enjoyed meeting all those people. I guess I’m just too tired of how our industry just does not get the difference between Domain-Driven Design and Object-Orientation.

Being specific, the reasons I am so tired are:

1. It seems to be extremely hard for people to understand Domain-Driven Design.
2. People don’t have to understand Domain-Driven Design to benefit from it

Please let me elaborate.

##It seems to be extremely hard for people to understand Domain-Driven Design

Let’s do a quick search on Google:

This is just a quick example of how people understand Domain-Driven Design: There are much more hits on Google about the Repository and Anti-Corruption Layer Patterns than about the Ubiquitous Language.

To better understand the problem this represents let’s revisit the book. The Ubiquitous Language is defined in Part I. Accordingly to the book, Part I “presents the basic goals of domain-driven development”. Just before that, in his foreword, Martin Fowler also says:

Eric also cements many of the things that we’ve learned over the years. First, in domain modeling, you shouldn’t separate the concepts from the implementation. An effective domain modeler can not only use a whiteboard with an accountant, but also write Java with a programmer. Partly this is true because you cannot build a useful conceptual model without considering implementation issues. But the primary reason why concepts and implementation belong together is this: The greatest value of a domain model is that it provides a ubiquitous language that ties domain experts and technologists together. ***

Sounds pretty important, doesn’t it?

The Repository Pattern, on the other hand, was catalogued by Fowler in his Patterns of Enterprise Application Architecture and is presented by Evans in Part II. The Author says that this part’s goal “is to focus on the kinds of decisions that keep the model and implementation aligned with each other, each reinforcing the other’s effectiveness”.

The large number of hits for the Anti-Corruption Layer is even more disturbing. It is presented in Part IV, and this part “enables the goals of Part I to be realized on a larger scale, for a big system or an application that fits into a sprawling, enterprise-wide network”.

That’s odd. A lot of people are talking about Eric Evans’ work and yet people seem to be more interested in the building blocks than in the actual core of Domain-Driven Design.

That was the reason that I created that workshop. All over forums and user groups people are talking about Domain-Driven Design as if it were just a modeling technique and/or a Pattern Language. Given that the Patterns and techniques that the book mentions are nothing new to Object-Orientation, I have to ask: if Domain-Driven Design is just about how create an object model, how is it different from what was developed in decades of Object-Orientation?

Repositories, Value Objects, Entities, Specifications… nothing about these is new. If Evans had written a book only to catalog these Patterns he would just be repeating what other people already said years ago. Is very unlikely that his work would have any relevancy or generate much interest.

But that’s not the case. Domain-Driven Design uses the Patterns, techniques and strategies to enable the only thing that this technique actually brings to the table: to keep model and implementation aligned and use a language that reflects this model. Quoting the book once more:

In domain-driven design, three basic uses determine the choice of a model.

1. The model and the heart of the design shape each other. […]

2. The model is the backbone of a language used by all team members. Because of the binding of model and implementation, developers can talk about the program in this language. They can communicate with domain experts without translation. And because the language is based on the model, our natural linguistic abilities can be turned to refining the model itself.

1. The model is distilled knowledge. ***

And this book does achieve the goal of showing how to bind model, language and implementation in a brilliant way. The problem is that people are just too much excited about shiny “new” Patterns to actually pay attention to what matters, even thought the author repeats that over and over throughout the book!

I guess the problem here may be caused by the fact that most people I know made Domain-Driven Design her first book on real-world Object-Oriented design. I don’t think it is a good book for this, actually I think it is a terrible choice. Evans’ book should be your third, maybe fourth book on the topic. It is much better to read it after having to fight against models that lack a unifying language.

##People don’t have to understand Domain-Driven Design to benefit from it

And this is probably a good thing. As a consultant I am always on client-side and always working with teams of different levels. Most often I have a team that know just the bare basics of Object-Orientation and can’t possibly digest concepts like those presented by Evans.

That’s ok though, they don’t have to. One of the good things about using the Domain-Driven Design way of thinking is that it provides you with a simple framework to figure out what –not how- to do; but the single best thing about Domain-Driven Design in most scenarios is that people don’t have to know the name of this technique.

In my workshops I explored that a lot. Only after four hours of multiple activities that focused only on modeling a domain, defining a language and refactoring it that I introduced the building blocks –and the only reason I introduced the Patterns during my workshop was because I had people that already had read the book and had questions to ask about that.

And that is the same kind of thing that I do with my teams. I will try to never use the words entity or value object but I will explain the different types of identity and lifecycle objects have. I will not say that we have a Repository of Users but I will model with them some class that represents a list of stuff.

My experience says that the book is not enough. My experience says that the workshop is not enough. My experience says that people have to see the goal of Domain-Driven Design by applying the Ubiquitous Language in an actual project.