Patterns, Principles, and Practices of Domain-Driven Design

Scott Millett is the Director of IT for Iglu.com, and has been working with .NET since version 1.0. He was awarded the ASP.NET MVP in 2010 and 2011, and is the author of Professional ASP.NET 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 xxxvPART I: THE PRINCIPLES AND PRACTICES OF DOMAIN‐DRIVEN DESIGNCHAPTER 1: WHAT IS DOMAIN‐DRIVEN DESIGN? 3The Challenges of Creating Software for Complex Problem Domains 4Code Created Without a Common Language 4A Lack of Organization 5The Ball of Mud Pattern Stifles Development 5A Lack of Focus on the Problem Domain 6How the Patterns of Domain‐Driven Design Manage Complexity 6The Strategic Patterns of DDD 6Distilling the Problem Domain to Reveal What Is Important 7Creating a Model to Solve Domain Problems 7Using a Shared Language to Enable Modeling Collaboration 7Isolate Models from Ambiguity and Corruption 8Understanding the Relationships between Contexts 9The Tactical Patterns of DDD 9The Problem Space and the Solution Space 9The Practices and Principles of Domain‐Driven Design 11Focusing on the Core Domain 11Learning through Collaboration 11Creating Models through Exploration and Experimentation 11Communication 11Understanding the Applicability of a Model 12Constantly Evolving the Model 12Popular Misconceptions of Domain‐Driven Design 12Tactical Patterns Are Key to DDD 12DDD Is a Framework 13DDD Is a Silver Bullet 13The Salient Points 13CHAPTER 2: DISTILLING THE PROBLEM DOMAIN 15Knowledge Crunching and Collaboration 15Reaching a Shared Understanding through a Shared Language 16The Importance of Domain Knowledge 17The Role of Business Analysts 17An Ongoing Process 17Gaining Domain Insight with Domain Experts 18Domain Experts vs Stakeholders 18Deeper Understanding for the Business 19Engaging with Your Domain Experts 19Patterns for Effective Knowledge Crunching 19Focus on the Most Interesting Conversations 19Start from the Use Cases 20Ask Powerful Questions 20Sketching 20Class Responsibility Collaboration Cards 21Defer the Naming of Concepts in Your Model 21Behavior‐Driven Development 22Rapid Prototyping 23Look at Paper‐Based Systems 24Look For Existing Models 24Understanding Intent 24Event Storming 25Impact Mapping 25Understanding the Business Model 27Deliberate Discovery 28Model Exploration Whirlpool 29The Salient Points 29CHAPTER 3: FOCUSING ON THE CORE DOMAIN 31Why Decompose a Problem Domain? 31How to Capture the Essence of the Problem 32Look Beyond Requirements 32Capture the Domain Vision for a Shared Understanding of What Is Core 32How to Focus on the Core Problem 33Distilling a Problem Domain 34Core Domains 35Treat Your Core Domain as a Product Rather than a Project 36Generic Domains 37Supporting Domains 37How Subdomains Shape a Solution 37Not All Parts of a System will be Well Designed 37Focus on Clean Boundaries over Perfect Models 38The Core Domain Doesn’t Always Have to Be Perfect the First Time 39Build Subdomains for Replacement Rather than Reuse 39What if You Have no Core Domain? 39The Salient Points 40CHAPTER 4: MODEL‐DRIVEN DESIGN 41What Is a Domain Model? 42The Domain versus the Domain Model 42The Analysis Model 43The Code Model 43The Code Model Is the Primary Expression of the Domain Model 44Model‐Driven Design 44The Challenges with Upfront Design 44Team Modeling 45Using a Ubiquitous Language to Bind the Analysis to the Code Model 47A Language Will Outlive Your Software 47The Language of the Business 48Translation between the Developers and the Business 48Collaborating on a Ubiquitous Language 48Carving Out a Language by Working with Concrete Examples 49Teach Your Domain Experts to Focus on the Problem and Not Jump to a Solution 50Best Practices for Shaping the Language 51How to Create Effective Domain Models 52Don’t Let the Truth Get in the Way of a Good Model 52Model Only What Is Relevant 54Domain Models Are Temporarily Useful 54Be Explicit with Terminology 54Limit Your Abstractions 54Focus Your Code at the Right Level of Abstraction 55Abstract Behavior Not Implementations 55Implement the Model in Code Early and Often 56Don’t Stop at the First Good Idea 56When to Apply Model‐Driven Design 56If It’s Not Worth the Effort Don’t Try and Model It 56Focus on the Core Domain 57The Salient Points 57CHAPTER 5: DOMAIN MODEL IMPLEMENTATION PATTERNS 59The Domain Layer 60Domain Model Implementation Patterns 60Domain Model 62Transaction Script 65Table Module 67Active Record 67Anemic Domain Model 67Anemic Domain Model and Functional Programming 68The Salient Points 71CHAPTER 6: MAINTAINING THE INTEGRITY OF DOMAIN MODELS WITH BOUNDED CONTEXTS 73The Challenges of a Single Model 74A Model Can Grow in Complexity 74Multiple Teams Working on a Single Model 74Ambiguity in the Language of the Model 75The Applicability of a Domain Concept 76Integration with Legacy Code or Third Party Code 78Your Domain Model Is not Your Enterprise Model 79Use Bounded Contexts to Divide and Conquer a Large Model 79Defining a Model’s Boundary 82Define Boundaries around Language 82Align to Business Capabilities 83Create Contexts around Teams 83Try to Retain Some Communication between Teams 84Context Game 85The Difference between a Subdomain and a Bounded Context 85Implementing Bounded Contexts 85The Salient Points 89CHAPTER 7: CONTEXT MAPPING 91A Reality Map 92The Technical Reality 92The Organizational Reality 93Mapping a Relevant Reality 94X Marks the Spot of the Core Domain 94Recognising the Relationships between Bounded Contexts 95Anticorruption Layer 95Shared Kernel 96Open Host Service 97Separate Ways 97Partnership 98An Upstream/Downstream Relationship 98Customer‐Supplier 99Conformist 100Communicating the Context Map 100The Strategic Importance of Context Maps 101Retaining Integrity 101The Basis for a Plan of Attack 101Understanding Ownership and Responsibility 101Revealing Areas of Confusion in Business Work Flow 102Identifying Nontechnical Obstacles 102Encourages Good Communication 102Helps On‐Board New Starters 102The Salient Points 103CHAPTER 8: APPLICATION ARCHITECTURE 105Application Architecture 105Separating the Concerns of Your Application 106Abstraction from the Complexities of the Domain 106A Layered Architecture 106Dependency Inversion 107The Domain Layer 107The Application Service Layer 108The Infrastructural Layers 108Communication Across Layers 108Testing in Isolation 109Don t Share Data Schema between Bounded Contexts 109Application Architectures versus Architectures for Bounded Contexts 111Application Services 112Application Logic versus Domain Logic 114Defining and Exposing Capabilities 114Business Use Case Coordination 115Application Services Represent Use Cases, Not Create, Read, Update, and Delete 115Domain Layer As an Implementation Detail 115Domain Reporting 116Read Models versus Transactional Models 116Application Clients 117The Salient Points 120CHAPTER 9: COMMON PROBLEMS FOR TEAMS STARTING OUT WITH DOMAIN‐DRIVEN DESIGN 121Overemphasizing the Importance of Tactical Patterns 122Using the Same Architecture for All Bounded Contexts 122Striving for Tactical Pattern Perfection 122Mistaking the Building Blocks for the Value of DDD 123Focusing on Code Rather Than the Principles of DDD 123Missing the Real Value of DDD: Collaboration, Communication, and Context 124Producing a Big Ball of Mud Due to Underestimating the Importance of Context 124Causing Ambiguity and Misinterpretations by Failing to Create a UL 125Designing Technical‐Focused Solutions Due to a Lack of Collaboration 125Spending Too Much Time on What’s Not Important 126Making Simple Problems Complex 126Applying DDD Principles to a Trivial Domain with Little Business Expectation 126Disregarding CRUD as an Antipattern 127Using the Domain Model Pattern for Every Bounded Context 127Ask Yourself: Is It Worth This Extra Complexity? 127Underestimating the Cost of Applying DDD 127Trying to Succeed Without a Motivated and Focused Team 128Attempting Collaboration When a Domain Expert Is Not Behind the Project 128Learning in a Noniterative Development Methodology 128Applying DDD to Every Problem 129Sacrificing Pragmatism for Needless Purity 129Wasted Effort by Seeking Validation 129Always Striving for Beautiful Code 130DDD Is About Providing Value 130The Salient Points 130CHAPTER 10: APPLYING THE PRINCIPLES, PRACTICES, AND PATTERNS OF DDD 131Selling DDD 132Educating Your Team 132Speaking to Your Business 132Applying the Principles of DDD 133Understand the Vision 133Capture the Required Behaviors 134Distilling the Problem Space 134Focus on What Is Important 134Understand the Reality of the Landscape 135Modeling a Solution 135All Problems Are Not Created Equal 136Engaging with an Expert 136Select a Behavior and Model Around a Concrete Scenario 137Collaborate with the Domain Expert on the Most Interesting Parts 137Evolve UL to Remove Ambiguity 138Throw Away Your First Model, and Your Second 138Implement the Model in Code 139Creating a Domain Model 139Keep the Solution Simple and Your Code Boring 139Carve Out an Area of Safety 140Integrate the Model Early and Often 140Nontechnical Refactoring 140Decompose Your Solution Space 140Rinse and Repeat 141Exploration and Experimentation 142Challenge Your Assumptions 142Modeling Is a Continuous Activity 142There Are No Wrong Models 142Supple Code Aids Discovery 143Making the Implicit Explicit 143Tackling Ambiguity 144Give Things a Name 145A Problem Solver First, A Technologist Second 146Don’t Solve All the Problems 146How Do I Know That I Am Doing It Right? 146Good Is Good Enough 147Practice, Practice, Practice 147The Salient Points 147PART II: STRATEGIC PATTERNS: COMMUNICATING BETWEEN BOUNDED CONTEXTSCHAPTER 11: INTRODUCTION TO BOUNDED CONTEXT INTEGRATION 151How to Integrate Bounded Contexts 152Bounded Contexts Are Autonomous 153The Challenges of Integrating Bounded Contexts at the Code Level 153Multiple Bounded Contexts Exist within a Solution 153Namespaces or Projects to Keep Bounded Contexts Separate 154Integrating via the Database 155Multiple Teams Working in a Single Codebase 156Models Blur 156Use Physical Boundaries to Enforce Clean Models 157Integrating with Legacy Systems 158Bubble Context 158Autonomous Bubble Context 158Exposing Legacy Systems as Services 160Integrating Distributed Bounded Contexts 161Integration Strategies for Distributed Bounded Contexts 161Database Integration 162Flat File Integration 163RPC 164Messaging 165REST 165The Challenges of DDD with Distributed Systems 165The Problem with RPC 166RPC Is Harder to Make Resilient 167RPC Costs More to Scale 167RPC Involves Tight Coupling 168Distributed Transactions Hurt Scalability and Reliability 169Bounded Contexts Don’t Have to Be Consistent with Each Other 169Eventual Consistency 169Event‐Driven Reactive DDD 170Demonstrating the Resilience and Scalability of Reactive Solutions 171Challenges and Trade‐Offs of Asynchronous Messaging 173Is RPC Still Relevant? 173SOA and Reactive DDD 174View Your Bounded Contexts as SOA Services 175Decompose Bounded Contexts into Business Components 175Decompose Business Components into Components 176Going Even Further with Micro Service Architecture 178The Salient Points 180CHAPTER 12: INTEGRATING VIA MESSAGING 181Messaging Fundamentals 182Message Bus 182Reliable Messaging 184Store‐and‐Forward 184Commands and Events 185Eventual Consistency 186Building an E‐Commerce Application with NServiceBus 186Designing the System 187Domain‐Driven Design 187Containers Diagrams 188Evolutionary Architecture 191Sending Commands from a Web Application 192Creating a Web Application to Send Messages with NServiceBus 192Sending Commands 197Handling Commands and Publishing Events 200Creating an NServiceBus Server to Handle Commands 200Configuring the Solution for Testing and Debugging 201Publishing Events 204Subscribing to Events 206Making External HTTP Calls Reliable with Messaging Gateways 208Messaging Gateways Improve Fault Tolerance 208Implementing a Messaging Gateway 209Controlling Message Retries 212Eventual Consistency in Practice 215Dealing with Inconsistency 215Rolling Forward into New States 215Bounded Contexts Store All the Data They Need Locally 216Storage Is Cheap—Keep a Local Copy 217Common Data Duplication Concerns 223Pulling It All Together in the UI 224Business Components Need Their Own APIs 225Be Wary of Server‐Side Orchestration 226UI Composition with AJAX Data 226UI Composition with AJAX HTML 226Sharing Your APIs with the Outside World 227Maintaining a Messaging Application 227Message Versioning 228Backward‐Compatible Message Versioning 228Handling Versioning with NServiceBus’s Polymorphic Handlers 229Monitoring and Scaling 233Monitoring Errors 233Monitoring SLAs 234Scaling Out 235Integrating a Bounded Context with Mass Transit 235Messaging Bridge 236Mass Transit 236Installing and Configuring Mass Transit 236Declaring Messages for Use by Mass Transit 238Creating a Message Handler 239Subscribing to Events 239Linking the Systems with a Messaging Bridge 240Publishing Events 242Testing It Out 243Where to Learn More about Mass Transit 243The Salient Points 243CHAPTER 13: INTEGRATING VIA HTTP WITH RPC AND REST 245Why Prefer HTTP? 247No Platform Coupling 247Everyone Understands HTTP 247Lots of Mature Tooling and Libraries 247Dogfooding Your APIs 247RPC 248Implementing RPC over HTTP 248SOAP 249Plain XML or JSON: The Modern Approach to RPC 259Choosing a Flavor of RPC 263REST 264Demystifying REST 264Resources 264Hypermedia 265Statelessness 265REST Fully Embraces HTTP 266What REST Is Not 267REST for Bounded Context Integration 268Designing for REST 268Building Event‐Driven REST Systems with ASP.NET Web API 273Maintaining REST Applications 303Versioning 303Monitoring and Metrics 303Drawbacks with REST for Bounded Context Integration 304Less Fault Tolerance Out of the Box 304Eventual Consistency 304The Salient Points 305PART III: TACTICAL PATTERNS: CREATING EFFECTIVE DOMAIN MODELSCHAPTER 14: INTRODUCING THE DOMAIN MODELING BUILDING BLOCKS 309Tactical Patterns 310Patterns to Model Your Domain 310Entities 310Value Objects 314Domain Services 317Modules 318Lifecycle Patterns 318Aggregates 318Factories 322Repositories 323Emerging Patterns 324Domain Events 324Event Sourcing 326The Salient Points 327CHAPTER 15: VALUE OBJECTS 329When to Use a Value Object 330Representing a Descriptive, Identity‐Less Concept 330Enhancing Explicitness 331Defining Characteristics 333Identity‐Less 333Attribute‐Based Equality 333Behavior‐Rich 337Cohesive 337Immutable 337Combinable 339Self‐Validating 341Testable 344Common Modeling Patterns 345Static Factory Methods 345Micro Types (Also Known as Tiny Types) 347Collection Aversion 349Persistence 35NoSQL 352SQL 353Flat Denormalization 353Normalizing into Separate Tables 357The Salient Points 359CHAPTER 16: ENTITIES 36Understanding Entities 362Domain Concepts with Identity and Continuity 362Context‐Dependent 363Implementing Entities 363Assigning Identifiers 363Natural Keys 363Arbitrarily Generated IDs 364Datastore‐Generated IDs 368Pushing Behavior into Value Objects and Domain Services 369Validating and Enforcing Invariants 371Focusing on Behavior, Not Data 374Avoiding the “Model the Real‐World” Fallacy 377Designing for Distribution 378Common Entity Modeling Principles and Patterns 380Implementing Validation and Invariants with Specifications 380Avoid the State Pattern; Use Explicit Modeling 382Avoiding Getters and Setters with the Memento Pattern 385Favor Hidden‐Side‐Effect‐Free Functions 386The Salient Points 388CHAPTER 17: DOMAIN SERVICES 389Understanding Domain Services 390When to Use a Domain Service 390Encapsulating Business Policies and Processes 390Representing Contracts 394Anatomy of a Domain Service 395Avoiding Anemic Domain Models 395Contrasting with Application Services 396Utilizing Domain Services 397In the Service Layer 397In the Domain 398Manually Wiring Up 399Using Dependency Injection 400Using a Service Locator 400Applying Double Dispatch 401Decoupling with Domain Events 402Should Entities Even Know About Domain Services? 403The Salient Points 403CHAPTER 18: DOMAIN EVENTS 405Essence of the Domain Events Pattern 406Important Domain Occurrences That Have Already Happened 406Reacting to Events 407Optional Asynchrony 407Internal vs External Events 408Event Handling Actions 409Invoke Domain Logic 409Invoke Application Logic 410Domain Events’ Implementation Patterns 410Use the .Net Framework’s Events Model 410Use an In‐Memory Bus 412Udi Dahan’s Static DomainEvents Class 415Handling Threading Issues 417Avoid a Static Class by Using Method Injection 418Return Domain Events 419Use an IoC Container as an Event Dispatcher 421Testing Domain Events 422Unit Testing 422Application Service Layer Testing 424The Salient Points 425CHAPTER 19: AGGREGATES 427Managing Complex Object Graphs 428Favoring a Single Traversal Direction 428Qualifying Associations 430Preferring IDs Over Object References 431Aggregates 434Design Around Domain Invariants 435Higher Level of Domain Abstraction 435Consistency Boundaries 435Transactional Consistency Internally 436Eventual Consistency Externally 439Special Cases 440Favor Smaller Aggregates 441Large Aggregates Can Degrade Performance 441Large Aggregates Are More Susceptible to Concurrency Conflicts 442Large Aggregates May Not Scale Well 442Defining Aggregate Boundaries 442eBidder: The Online Auction Case Study 443Aligning with Invariants 444Aligning with Transactions and Consistency 446Ignoring User Interface Influences 448Avoiding Dumb Collections and Containers 448Don’t Focus on HAS‐A Relationships 449Refactoring to Aggregates 449Satisfying Business Use Cases—Not Real Life 449Implementing Aggregates 450Selecting an Aggregate Root 450Exposing Behavioral Interfaces 452Protecting Internal State 453Allowing Only Roots to Have Global Identity 454Referencing Other Aggregates 454Nothing Outside An Aggregate’s Boundary May Hold a Reference to Anything Inside 455The Aggregate Root Can Hand Out Transient References to the Internal Domain Objects 456Objects within the Aggregate Can Hold References to Other Aggregate Roots 456Implementing Persistence 458Access to Domain Objects for Reading Can Be at the Database Level 460A Delete Operation Must Remove Everything within the Aggregate Boundary at Once 461Avoiding Lazy Loading 461Implementing Transactional Consistency 462Implementing Eventual Consistency 463Rules That Span Multiple Aggregates 463Asynchronous Eventual Consistency 464Implementing Concurrency 465The Salient Points 468CHAPTER 20: FACTORIES 469The Role of a Factory 469Separating Use from Construction 470Encapsulating Internals 470Hiding Decisions on Creation Type 472Factory Methods on Aggregates 474Factories for Reconstitution 475Use Factories Pragmatically 477The Salient Points 477CHAPTER 21: REPOSITORIES 479Repositories 479A Misunderstood Pattern 481Is the Repository an Antipattern? 481The Difference between a Domain Model and a Persistence Model 482The Generic Repository 483Aggregate Persistence Strategies 486Using a Persistence Framework That Can Map the Domain Model to the Data Model without Compromise 486Using a Persistence Framework That Cannot Map the Domain Model Directly without Compromise 487Public Getters and Setters 487Using the Memento Pattern 488Event Streams 49Be Pragmatic 491A Repository Is an Explicit Contract 492Transaction Management and Units of Work 493To Save or Not To Save 497Persistence Frameworks That Track Domain Object Changes 497Having to Explicitly Save Changes to Aggregates 498The Repository as an Anticorruption Layer 499Other Responsibilities of a Repository 500Entity ID Generation 500Collection Summaries 502Concurrency 503Audit Trails 506Repository Antipatterns 506Antipatterns: Don’t Support Ad Hoc Queries 506Antipatterns: Lazy Loading Is Design Smell 507Antipatterns: Don’t Use Repositories for Reporting Needs 507Repository Implementations 508Persistence Framework Can Map Domain Model to Data Model without Compromise 509NHibernate Example 509RavenDB Example 543Persistence Framework Cannot Map Domain Model Directly without Compromise 557Entity Framework Example 558Micro ORM Example 577The Salient Points 593CHAPTER 22: EVENT SOURCING 595The Limitations of Storing State as a Snapshot 596Gaining Competitive Advantage by Storing State as a Stream of Events 597Temporal Queries 597Projections 599Snapshots 599Event‐Sourced Aggregates 600Structuring 600Adding Event‐Sourcing Capabilities 601Exposing Expressive Domain‐Focused APIs 602Adding Snapshot Support 604Persisting and Rehydrating 605Creating an Event-Sourcing Repository 605Adding Snapshot Persistence and Reloading 607Handling Concurrency 609Testing 610Building an Event Store 611Designing a Storage Format 612Creating Event Streams 614Appending to Event Streams 614Querying Event Streams 615Adding Snapshot Support 616Managing Concurrency 618A SQL Server‐Based Event Store 621Choosing a Schema 621Creating a Stream 622Saving Events 623Loading Events from a Stream 624Snapshots 625Is Building Your Own Event Store a Good Idea? 627Using the Purpose‐Built Event Store 627Installing Greg Young’s Event Store 628Using the C# Client Library 627Running Temporal Queries 632Querying a Single Stream 632Querying Multiple Streams 634Creating Projections 635CQRS with Event Sourcing 637Using Projections to Create View Caches 638CQRS and Event Sourcing Synergy 638Event Streams as Queues 639No Two‐Phase Commits 639Recapping the Benefits of Event Sourcing 639Competitive Business Advantage 639Expressive Behavior‐Focused Aggregates 639Simplified Persistence 640Superior Debugging 640Weighing the Costs of Event Sourcing 640Versioning 640New Concepts to Learn and Skills to Hone 640New Technologies to Learn and Master 641Greater Data Storage Requirements 641Additional Learning Resources 641The Salient Points 641PART IV: DESIGN PATTERNS FOR EFFECTIVE APPLICATIONSCHAPTER 23: ARCHITECTING APPLICATION USER INTERFACES 645Design Considerations 646Owned UIs versus Composed UIs 646Autonomous 646Authoritative 647Some Help Deciding 648HTML APIs versus Data APIs 649Client versus Server‐Side Aggregation/Coordination 649Example 1: An HTML API‐Based, Server‐Side UI for Nondistributed Bounded Contexts 651Example 2: A Data API‐Based, Client‐Side UI for Distributed Bounded Contexts 658The Salient Points 667CHAPTER 24: CQRS: AN ARCHITECTURE OF A BOUNDED CONTEXT 669The Challenges of Maintaining a Single Model for Two Contexts 670A Better Architecture for Complex Bounded Contexts 670The Command Side: Business Tasks 672Explicitly Modeling Intent 672A Model Free from Presentational Distractions 674Handling a Business Request 675The Query Side: Domain Reporting 676Reports Mapped Directly to the Data Model 676Materialized Views Built from Domain Events 678The Misconceptions of CQRS 679CQRS Is Hard 679CQRS Is Eventually Consistent 679Your Models Need to Be Event Sourced 680Commands Should Be Asynchronous 680CQRS Only Works with Messaging Systems 680You Need to Use Domain Events with CQRS 680Patterns to Enable Your Application to Scale 680Scaling the Read Side: An Eventually Consistent Read Model 681The Impact to the User Experience 682Use the Read Model to Consolidate Many Bounded Contexts 682Using a Reporting Database or a Caching Layer 682Scaling the Write Side: Using Asynchronous Commands 683Command Validation 683Impact to the User Experience 684Scaling It All 684The Salient Points 685CHAPTER 25: COMMANDS: APPLICATION SERVICE PATTERNS FOR PROCESSING BUSINESS USE CASES 687Differentiating Application Logic and Domain Logic 689Application Logic 689Infrastructural Concerns 690Coordinating Full Business Use Cases 698Application Services and Framework Integration 698Domain Logic from an Application Service’s Perspective 700Application Service Patterns 700Command Processor 701Publish/Subscribe 704Request/Reply Pattern 706async/await 708Testing Application Services 709Use Domain Terminology 709Test as Much Functionality as Possible 710The Salient Points 712CHAPTER 26: QUERIES: DOMAIN REPORTING 713Domain Reporting within a Bounded Context 714Deriving Reports from Domain Objects 714Using Simple Mappings 714Using the Mediator Pattern 718Going Directly to the Datastore 720Querying a Datastore 721Reading Denormalized View Caches 724Building Projections from Event Streams 726Setting Up ES for Projections 727Creating Reporting Projections 728Counting the Number of Events in a Stream 729Creating As Many Streams As Required 729Building a Report from Streams and Projections 730Domain Reporting Across Bounded Contexts 733Composed UI 733Separate Reporting Context 734The Salient Points 736INDEX 737