Scott Millett is the Director of IT for [...], and has been working with .NET since version 1.0. He was awarded the [...] MVP in 2010 and 2011, and is the author of Professional [...] Design Patterns and Professional Enterprise .NET.

Nick Tune is a software developer delivering solutions to complex business problems using technology, collaboration, and Domain-Driven Design. He continually seeks improvement by working on ambitious products and with enthusiastic people.

INTRODUCTION xxxv

PART I: THE PRINCIPLES AND PRACTICES OF DOMAIN¿DRIVEN DESIGN

CHAPTER 1: WHAT IS DOMAIN¿DRIVEN DESIGN? 3

The Challenges of Creating Software for Complex Problem Domains 4

Code Created Without a Common Language 4

A Lack of Organization 5

The Ball of Mud Pattern Stifles Development 5

A Lack of Focus on the Problem Domain 6

How the Patterns of Domain¿Driven Design Manage Complexity 6

The Strategic Patterns of DDD 6

Distilling the Problem Domain to Reveal What Is Important 7

Creating a Model to Solve Domain Problems 7

Using a Shared Language to Enable Modeling Collaboration 7

Isolate Models from Ambiguity and Corruption 8

Understanding the Relationships between Contexts 9

The Tactical Patterns of DDD 9

The Problem Space and the Solution Space 9

The Practices and Principles of Domain¿Driven Design 11

Focusing on the Core Domain 11

Learning through Collaboration 11

Creating Models through Exploration and Experimentation 11

Communication 11

Understanding the Applicability of a Model 12

Constantly Evolving the Model 12

Popular Misconceptions of Domain¿Driven Design 12

Tactical Patterns Are Key to DDD 12

DDD Is a Framework 13

DDD Is a Silver Bullet 13

The Salient Points 13

CHAPTER 2: DISTILLING THE PROBLEM DOMAIN 15

Knowledge Crunching and Collaboration 15

Reaching a Shared Understanding through a Shared Language 16

The Importance of Domain Knowledge 17

The Role of Business Analysts 17

An Ongoing Process 17

Gaining Domain Insight with Domain Experts 18

Domain Experts vs Stakeholders 18

Deeper Understanding for the Business 19

Engaging with Your Domain Experts 19

Patterns for Effective Knowledge Crunching 19

Focus on the Most Interesting Conversations 19

Start from the Use Cases 20

Ask Powerful Questions 20

Sketching 20

Class Responsibility Collaboration Cards 21

Defer the Naming of Concepts in Your Model 21

Behavior¿Driven Development 22

Rapid Prototyping 23

Look at Paper¿Based Systems 24

Look For Existing Models 24

Understanding Intent 24

Event Storming 25

Impact Mapping 25

Understanding the Business Model 27

Deliberate Discovery 28

Model Exploration Whirlpool 29

The Salient Points 29

CHAPTER 3: FOCUSING ON THE CORE DOMAIN 31

Why Decompose a Problem Domain? 31

How to Capture the Essence of the Problem 32

Look Beyond Requirements 32

Capture the Domain Vision for a Shared Understanding of What Is Core 32

How to Focus on the Core Problem 33

Distilling a Problem Domain 34

Core Domains 35

Treat Your Core Domain as a Product Rather than a Project 36

Generic Domains 37

Supporting Domains 37

How Subdomains Shape a Solution 37

Not All Parts of a System will be Well Designed 37

Focus on Clean Boundaries over Perfect Models 38

The Core Domain Doesn't Always Have to Be Perfect the First Time 39

Build Subdomains for Replacement Rather than Reuse 39

What if You Have no Core Domain? 39

The Salient Points 40

CHAPTER 4: MODEL¿DRIVEN DESIGN 41

What Is a Domain Model? 42

The Domain versus the Domain Model 42

The Analysis Model 43

The Code Model 43

The Code Model Is the Primary Expression of the Domain Model 44

Model¿Driven Design 44

The Challenges with Upfront Design 44

Team Modeling 45

Using a Ubiquitous Language to Bind the Analysis to the Code Model 47

A Language Will Outlive Your Software 47

The Language of the Business 48

Translation between the Developers and the Business 48

Collaborating on a Ubiquitous Language 48

Carving Out a Language by Working with Concrete Examples 49

Teach Your Domain Experts to Focus on the Problem and Not Jump to a Solution 50

Best Practices for Shaping the Language 51

How to Create Effective Domain Models 52

Don't Let the Truth Get in the Way of a Good Model 52

Model Only What Is Relevant 54

Domain Models Are Temporarily Useful 54

Be Explicit with Terminology 54

Limit Your Abstractions 54

Focus Your Code at the Right Level of Abstraction 55

Abstract Behavior Not Implementations 55

Implement the Model in Code Early and Often 56

Don't Stop at the First Good Idea 56

When to Apply Model¿Driven Design 56

If It's Not Worth the Effort Don't Try and Model It 56

Focus on the Core Domain 57

The Salient Points 57

CHAPTER 5: DOMAIN MODEL IMPLEMENTATION PATTERNS 59

The Domain Layer 60

Domain Model Implementation Patterns 60

Domain Model 62

Transaction Script 65

Table Module 67

Active Record 67

Anemic Domain Model 67

Anemic Domain Model and Functional Programming 68

The Salient Points 71

CHAPTER 6: MAINTAINING THE INTEGRITY OF DOMAIN MODELS WITH BOUNDED CONTEXTS 73

The Challenges of a Single Model 74

A Model Can Grow in Complexity 74

Multiple Teams Working on a Single Model 74

Ambiguity in the Language of the Model 75

The Applicability of a Domain Concept 76

Integration with Legacy Code or Third Party Code 78

Your Domain Model Is not Your Enterprise Model 79

Use Bounded Contexts to Divide and Conquer a Large Model 79

Defining a Model's Boundary 82

Define Boundaries around Language 82

Align to Business Capabilities 83

Create Contexts around Teams 83

Try to Retain Some Communication between Teams 84

Context Game 85

The Difference between a Subdomain and a Bounded Context 85

Implementing Bounded Contexts 85

The Salient Points 89

CHAPTER 7: CONTEXT MAPPING 91

A Reality Map 92

The Technical Reality 92

The Organizational Reality 93

Mapping a Relevant Reality 94

X Marks the Spot of the Core Domain 94

Recognising the Relationships between Bounded Contexts 95

Anticorruption Layer 95

Shared Kernel 96

Open Host Service 97

Separate Ways 97

Partnership 98

An Upstream/Downstream Relationship 98

Customer¿Supplier 99

Conformist 100

Communicating the Context Map 100

The Strategic Importance of Context Maps 101

Retaining Integrity 101

The Basis for a Plan of Attack 101

Understanding Ownership and Responsibility 101

Revealing Areas of Confusion in Business Work Flow 102

Identifying Nontechnical Obstacles 102

Encourages Good Communication 102

Helps On¿Board New Starters 102

The Salient Points 103

CHAPTER 8: APPLICATION ARCHITECTURE 105

Application Architecture 105

Separating the Concerns of Your Application 106

Abstraction from the Complexities of the Domain 106

A Layered Architecture 106

Dependency Inversion 107

The Domain Layer 107

The Application Service Layer 108

The Infrastructural Layers 108

Communication Across Layers 108

Testing in Isolation 109

Don t Share Data Schema between Bounded Contexts 109

Application Architectures versus Architectures for Bounded Contexts 111

Application Services 112

Application Logic versus Domain Logic 114

Defining and Exposing Capabilities 114

Business Use Case Coordination 115

Application Services Represent Use Cases, Not Create, Read, Update, and Delete 115

Domain Layer As an Implementation Detail 115

Domain Reporting 116

Read Models versus Transactional Models 116

Application Clients 117

The Salient Points 120

CHAPTER 9: COMMON PROBLEMS FOR TEAMS STARTING OUT WITH DOMAIN¿DRIVEN DESIGN 121

Overemphasizing the Importance of Tactical Patterns 122

Using the Same Architecture for All Bounded Contexts 122

Striving for Tactical Pattern Perfection 122

Mistaking the Building Blocks for the Value of DDD 123

Focusing on Code Rather Than the Principles of DDD 123

Missing the Real Value of DDD: Collaboration, Communication, and Context 124

Producing a Big Ball of Mud Due to Underestimating the Importance of Context 124

Causing Ambiguity and Misinterpretations by Failing to Create a UL 125

Designing Technical¿Focused Solutions Due to a Lack of Collaboration 125

Spending Too Much Time on What's Not Important 126

Making Simple Problems Complex 126

Applying DDD Principles to a Trivial Domain with Little Business Expectation 126

Disregarding CRUD as an Antipattern 127

Using the Domain Model Pattern for Every Bounded Context 127

Ask Yourself: Is It Worth This Extra Complexity? 127

Underestimating the Cost of Applying DDD 127

Trying to Succeed Without a Motivated and Focused Team 128

Attempting Collaboration When a Domain Expert Is Not Behind the Project 128

Learning in a Noniterative Development Methodology 128

Applying DDD to Every Problem 129

Sacrificing Pragmatism for Needless Purity 129

Wasted Effort by Seeking Validation 129

Always Striving for Beautiful Code 130

DDD Is About Providing Value 130

The Salient Points 130

CHAPTER 10: APPLYING THE PRINCIPLES, PRACTICES, AND PATTERNS OF DDD 131

Selling DDD 132

Educating Your Team 132

Speaking to Your Business 132

Applying the Principles of DDD 133

Understand the Vision 133