PPPDDD.1 – What is Domain Driven Design?

Building software that works is not difficult.

What is indeed difficult is to build software that lasts for many years, that keeps working despite the changes needed by the business, needed by the users, needed by new technologies. Building software that is permanently ready for change, and permanently and accurately reflects the business… thats the tricky part.

There are many principles and techniques that help in achieving this goal, like SOLID, GRASP, STUPID, KISS, Law of Demeter, and others. DDD is a set of Patterns, Principles and Practices that help achieve this goal.

Domain-Driven Design (DDD) is a development philosophy defined by Eric Evans in his seminal work Domain-Driven Design: Tackling Complexity in the Heart of Software (Addison-Wesley Professional, 2003). DDD is an approach to software development that enables teams to effectively manage the construction and maintenance of software for complex problem domains.

Pg.3

In DDD philosophy, the main reason why software becomes complex and difficult to manage, is that the domain concepts are not clear, they tend to get mixed, inaccurate, and therefore rotten. They turn into code that is not structured, sloppy, coupled, opaque, spaghetti, in fact a Big Ball of Mud (BBoM) as defined by Brian Foote and Joseph Yoder in their paper “Big Ball of Mud”.

Then, communication is key. The business managers and the developers need a common language to talk about the business concepts. This is key to create a code base that reflects the intent of the business, the business concepts. In DDD, this is common language is called the Ubiquitous Language (UL). The UL is key when domain experts and developers cooperatively build a model of the business concepts, a Domain Model, that can be coded and accurately reflect the intent of the business.

Practices and Principles of DDD

1. Focus in the core domain
2. Learn through collaboration between developers and domain experts
3. Create models through exploration and experimentation, in order to better understand the domain and better reflect it in the code
4. Communicate clearly and without ambiguity, using a UL and reflecting it within the code
5. Understand the applicability of a model, segregate it in different models (bounded contexts) when new concepts emerge
6. Constantly evolve the model as new insights emerge

Misconceptions of DDD

1. “Tactical patterns are key to DDD”
   Tactical patterns (Design Patterns like Factories, Repositories, Entities, …) are not the most important concepts in DDD. DDD is not a code-centric philosophy, it is in fact all about domain understanding, collaboration and communication.
2. “DDD is a framework”
   DDD is architecturally agnostic, it does not require a special technical tool. It is about a mindset, and clearly separating the business concepts in bounded contexts.
3. “DDD is a silver bullet”
   DDD takes effort and is an iterative methodology. It is not an approach to to use in all projects, only in projects with a complex domain who actually requires effort in understanding and modeling.

This post is part of a set of posts with my personal notes about all the chapters in the book “Patterns Principles and Practices of Domain-Driven Design” by Scott Millett and Nick Tune. I will do this as I read through the book, and take notes on the concepts I personally find more relevant.