Domain-Driven Design

Domain-Driven Design (DDD) is a term introduced in the 2004 book of the same name—http://domaindrivendesign.org/books/evans_2003, though most of its principles have been around quite a bit longer among practitioners of object-oriented analysis and design. Indeed, the core of DDD can be thought of as deriving from the simulation techniques employed in Simula 67 – a language that influenced the design of C++.

Simply put, much software (particularly "enterprise" software) is created as a solution to a particular problem. Therefore, software should be designed by software experts in conjunction with domain experts. They should use a shared model of the problem domain, so that it's clear the whole team is trying to solve the same problem.

In an attempt to reduce communication problems, a "ubiquitous language" is defined – a common glossary of terms that's used throughout the documentation and the software. This includes the source code – classes and methods are named using the ubiquitous language to reflect the parts of the problem they address.

I think it was learning some of the principles of domain-driven design that finally made Object-Oriented programming (OOP) "click" with me (there's more on OOP later in this chapter). I'd been doing C and Pascal programming for a long time when I started to approach languages such as C++ and Java. While I could see that methods belonged to classes, in much the same way that modules work, deciding what should be an object, where its boundaries were, and how it interacted with other objects took me a long time to get to grips with.

At some point, I went on a training course that talked about domain modelling – and made it very simple. The core of it went something like this: listen to a domain expert describing a problem. Whenever they describe a concept in the problem domain with a noun, that's a candidate class, or maybe an attribute of a class. Whenever something's described as a verb, that's a candidate for a method.

That short description of how to translate a problem specification into objects and actions was a huge eye-opener for me; I can't think about OOP in any other way.