Hjem

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 DomainDriven 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 DomainDriven 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 DomainDriven 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 BehaviorDriven Development 22 Rapid Prototyping 23 Look at PaperBased 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 ModelDriven 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 ModelDriven 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 CustomerSupplier 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 OnBoard 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 TechnicalFocused 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 Busi