Review: Domain-Driven Design

When I wrote my first computer program in BASIC I didn't know anything about software design. My variable names used to be mathematically short and contain a lot of numbers. I wrote tightly coupled functions without parameters and synchronized the whole mess by a myriad of unstructured global data.

This is what naturally happens when you grow software over a period of time. Since I didn't have the mathematical background at the age of thirteen, short variable names seem to be a natural choice for human beings. You start with a seed and add functionality on a step-by-step basis, breaking up stuff at arbitrary boundaries.

I did appreciate the advantages of high level languages, though. When the 64k of BASIC data space and the interpreter's performance limited my possibilities with regards to game programming, I started using C as primary language with some inline assembler for the critical parts. At that time I created my first library package for graphical functions and prototyped some game built upon this foundation.

This was my first technical domain abstraction. Splitting up the software in a library component and a domain component came naturally back than. Of course the library design was crappy and the programs were still tightly coupled to the library implementation.

At that time I also tried to learn C++ from the Borland C++ programming reference, but I couldn't grasp the concepts. I probably didn't really try to, thinking that I already knew how to create working software - I had a nice working repository of gimicks at that time.

The next critical step in my understanding of software design was to drop my arrogance.

One of my first software engineering classes at university covered the basics of object oriented software development in C++ using the STL. The first exercise we had to finish was a small program of which I don't even remember what it was all about. A friend of mine and I worked on this exercise together. We both had programming experience and had a lot of fun hacking together a sharp-witted mess of code. The teaching assistant took his time to comment on every single part we messed up, giving us an overall rating of zero points.

This was the day I started to realize that the main challenge in programming is not to get a working program, but to create a maintainable, readable and easy to debug program.

At university I took part in a few programming projects and started an open source project with a fellow student. During those experiences I developed a strong sense of how structured abstraction can simplify software development. Then I started to work as a software developer and architect. When trying to communicate my architecture and design ideas, I realized that there are more aspects to software design than abstraction, low coupling and high cohesion. But, again, I couldn't grasp the concepts.

"Domain-Driven Design" is all about this additional aspect to good software design - the domain language. You can build a piece of software with low coupling and high cohesion and superb technical abstractions in a technical language that restricts software evolution.

Eric Evans proposes a domain languages built upon phrases that describe the implementation of use cases in the software. This is a concept very similiar to test driven development, where you write down how you want to use your objects before implementing them, being able to change the design while writing the test.

But in "Domain-Driven Design" Evans demands a stronger concept: absorb the domain language from the domain experts. Build a coherent language to express concepts and design descisions.

The model couples the software to a pool of associations.

This is a new level of coupling encountered when building software. It is not related to the technical coupling of software modules. This is just what goes on in the brains of developers when confronted with software. The underlying model limits the way we think about software. This is not always bad, as a good model will bind the parts that are irrelevant during development and allows us to concentrate on the important aspects.

A domain driven model increases the probability that modules may be reused in the domain the software is developed for.

While many developers intuitively know what domain driven design is all about, Eric Evans manages to communicate the concepts in a way that makes them explicit, rather than implicitely hidden in the developers train of thought.

The book is not a page-turner, since most of the concepts are not new per se. It lacks the driven spirit of Kent Beck, or the deep insight of Fred Brook's "Mythical Man Month". I can't say if "Domain-Driven Design" can help a student to boost design comprehension - I think it's rather hard to read if you lack the medium level knowledge the concepts in this book are built upon. But I recommend this book to those that already know what software design is all about intuitively and want to be able to put a finger upon the "big picture".