What Is Domain-Driven Design?

Introduction

Software engineering is hard. How hard? Enough that approximately 70% of software projects are not successfully delivered on time, on budget, or according to the client’s requirements. In other words, the vast majority of projects fail. This issue is so deep and widespread that we even have a term for it: the software crisis.

Many studies have been conducted to investigate the reasons for this crisis.¹ Although researchers have not been able to pinpoint a single cause, most of their findings share a common theme: communication. Communication issues can manifest themselves in different ways; for example, unclear requirements, uncertain project goals, or ineffective coordination of effort between teams.

Over the years, the software engineering industry has tried to improve inter- and intra-team communication by introducing new communication opportunities, processes, and mediums. Unfortunately, the success rates of our projects didn’t change much.

Domain-driven design (DDD) proposes to attack the software crisis and communication issues from a different angle.

What Is Domain-Driven Design?

DDD is a methodology that covers the whole software development lifecycle, from gathering requirements to low-level design. Its core premise is that to build better software, we have to align its design with the business’s domain, needs, and strategy. That’s where the name comes from: (business) domain-driven (software) design.

DDD proposes to align business and technical concerns through analysis of the business domain, modeling of the problem domain—the problems that should be solved by the software—and making design decisions according to the model of the problem domain. It provides tools for making design decisions on two levels: strategic and tactical.

Strategic Design

DDD’s strategic patterns and practices provide a framework for analyzing a company’s business domain and distilling the software’s problem domain—i.e., what problems should be solved or addressed by the software.

The strategic tools also provide a robust framework for making high-level architectural decisions, including tasks such as decomposing a system into modular components and mapping the interaction patterns between them.

Tactical Design

DDD’s tactical patterns support making low-level design decisions relating to the implementation of the system’s components and their business logic.

The goal of tactical design is to architect the solution so that it fits the problem domain as closely as possible.

Report Structure

This report introduces the strategic and tactical patterns and practices of domain-driven design:

• Part I, Strategic Design, introduces tools and techniques for business domain analysis, knowledge sharing, and overall strategic decision making.

• Part II, Tactical Design, touches on the low-level design concerns. It introduces different architectural and design patterns for implementing systems’ components.

• Part III, DDD in Practice, takes the concepts introduced in the first two parts from theory to practice. It introduces methods and tips for streamlining the adoption of domain-driven design in real life.

Most importantly, this report will show you how the alignment of your software’s design with its business domain positively contributes to your projects’ success rates.

¹ See, for example, Kaur, Rupinder, and Jyotsna Sengupta. 2013. “Software Process Models and Analysis on Failure of Software Development Projects.” arXiv preprint arXiv:1306.1068. https://arxiv.org/abs/1306.1068. See also Sudhakar, Goparaju Purna. 2012. “A Model of Critical Success Factors for Software Projects.” Journal of Enterprise Information Management 25 (6): 537–558.