Evans E., Domain-Driven Design (2004)

 |  Book Reviews

Successful business applications are among the most efficient and effective investments. DDD provides a unique engineering foundation to build such applications. The blue book is a must-practice resource for every OO business software developer to learn DDD.

Contents

Summary

Business software application modeling (object-oriented analysis and design (OOAD)), sometimes called object decomposition, is the critical skill required after requirements are elicited and architectures are outlined. God Objects, Big Ball of Mud, and many others1 are examples of OOP code smells that typically emerge when developers lack OOAD skills.

For a beginner developer from the outset the book gives a developer basic OOAD tools - a list of model objects with predefined data and responsibilities 2. There are only 6 model types 3 that greatly simplify application modeling, object decomposition. Even with naive, straightforward application they help much to pre-separate behavior (SoC, SRP) and data (encapsulation) among domain objects 4.

The other three key concepts that help further isolate problem domain areas are: Domain (ch. 1), Subdomains, Bounded Contexts (ch. 14), and Ubiquitous Languages (ch. 2).

The other crucial concept to separate the Domain from other concerns is architecture (ch. 4) (select whichever feels more comfortable to you: Layered (N-Tier), Onion (Clean) , Ports/Adapters (Hexagonal)).

I encourage aspiring application developers to study the book on their own starting from applying tactical patterns - even naively at first. This will naturally cultivate good coding practices. As you grow professionally, revisit this book and two other DDD books mentioned here to hone your skills.

Content Structure

The book contains 4 parts.

Part I: Putting the Domain Model to Work

It introduces the domain modeling process as it usually goes in software projects.

  • Crunching Knowledge (ch. 1): requirements elicitation;
  • Communication and the Use of Language (ch. 2): introduce the basic DDD concept of Ubiquitous Language as domain knowledge medium;
  • Binding Model and Implementation (ch3.): introduces Model-Drive Design, the modeling tool, that literally maps the domain model to the implementation;

Part II: The Building Blocks of a Model-Driven Design

The part transitions to building the application.

It describes the architecture as a means to isolate domain concerns from the other application concerns (Isolating the Domain, ch. 4).

Then it introduces the main building blocks of DDD: Entities, Value Objects, Services, Factories, Aggregates and Repositories (A Model Expressed in Software, ch. 5 and The Life Cycle of a Domain Object, ch. 6).

Finally it provides the concrete DDD application design example in Using the Language: An Extended Example (ch. 7).

[NOWADAYS] The part introduces the so-called Smart UI Anti-pattern (p. 76). In the 2020s, the context of this pattern revolves around the simple, likely only CRUD-like applications. The tools used alongside are low-code / no-code solutions, pre-fabricated application templates, specialized SaaS platforms allowing programmatic customization, RAD frameworks, LLM coding tools.

The advantages and the disadvantages, meanwhile, remain the same.

[IMPORTANT] However, from a business standpoint, a fact often overlooked by businesses - these applications are a waste of time, money and are lost opportunities of the business to obtain domain knowledge on how to make digital products 5 in its target markets.

This is because refactoring a simple CRUD applications built with Smart UI Anti-pattern into something valuable enough is much more expensive than throwing that CRUD away and building the real product - not a toy - using DDD from the outset.

Finally, producing top-quality code is fast, faster than low quality code. So decide with care.

Part III: Refactoring Toward Deeper Insight

This part is not for beginners and I leave it for a reader's self-study. It addresses the challenge of finding valuable models that capture deep understanding of the domain. It emphasizes the discovery process through an iterative process of refactoring. This involves transforming the design again and again as the team gains insight into the domain.

Part IV: Strategic Design

This final part deals with situations arising in complex systems, larger organizations, and interactions with external or legacy systems. It presents principles to scale the modeling process, focusing on strategic decisions made by teams.

It introduces around 14 new DDD terms to manage complexity on a larger scale. Left for for a reader self-study.

At A Glance Diagrams

These two diagrams bring big picture about the main notions and their relations in DDD with references to the book pages.

1.png
2.png

Closing

Here I explicitly mention two other books that should be absorbed to practice DDD happily: Vernon V., Implementing Domain-Driven Design (2015), Vernon V., Domain-Driven Design Distilled (2016).

Footnotes

  1. Data Class (Anemic Model), Primitive Obsession, Feature Envy, Lazy Class, Speculative Generality. For comprehensive studies of the clean code and OOAD anti-patterns and code smells see: Fowler M. Refactoring (1999, 2018), Kerievsky J., Refactoring to Patterns (2004), Martin R., Clean Code (2008), McConnell S., Code Complete (2004, 2016) ↩

  2. See chapters 5 and 6. Also called tactical DDD patterns: see Vernon V., Implementing Domain-Driven Design (2015) (p. 36), Vernon V., Domain-Driven Design Distilled (2016) (p. 19). ↩

  3. Entities, Value Objects, Services, Domain Events, Aggregates, Repositories. See [Vernon (2015)] chapters 5, 6, 7, 8, 10 and 12 respectively. ↩

  4. See Separation of Concerns, Single-Responsibility Principle, Encapsulation. ↩

  5. The knowledge retained by the business is minimal in this case: inexperienced teams, rushing schedules, no engineering processes (requirements, modeling) leave little or poor unusable domain documentation therefore wasting what instead could have been frugally invested in and reused by the business for many years to come. ↩