Details

Patterns, Principles, and Practices of Domain-Driven Design

1. Aufl.

von: Scott Millett, Nick Tune
39,99 €
Verlag:	Wiley
Format:	EPUB
Veröffentl.:	20.04.2015
ISBN/EAN:	9781118714690
Sprache:	englisch
Anzahl Seiten:	800

In den Warenkorb

Als Gutschein

DRM-geschütztes eBook, Sie benötigen z.B. Adobe Digital Editions und eine Adobe ID zum Lesen.

Beschreibungen

Titelbeschreibung

Methods for managing complex software construction following the practices, principles and patterns of Domain-Driven Design with code examples in C# This book presents the philosophy of Domain-Driven Design (DDD) in a down-to-earth and practical manner for experienced developers building applications for complex domains. A focus is placed on the principles and practices of decomposing a complex problem space as well as the implementation patterns and best practices for shaping a maintainable solution space. You will learn how to build effective domain models through the use of tactical patterns and how to retain their integrity by applying the strategic patterns of DDD. Full end-to-end coding examples demonstrate techniques for integrating a decomposed and distributed solution space while coding best practices and patterns advise you on how to architect applications for maintenance and scale. <ul> <li>Offers a thorough introduction to the philosophy of DDD for professional developers</li> <li>Includes masses of code and examples of concept in action that other books have only covered theoretically</li> <li>Covers the patterns of CQRS, Messaging, REST, Event Sourcing and Event-Driven Architectures</li> <li>Also ideal for Java developers who want to better understand the implementation of DDD</li> </ul>

Inhaltsverzeichnis

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 Capture the Required Behaviors 134 Distilling the Problem Space 134 Focus on What Is Important 134 Understand the Reality of the Landscape 135 Modeling a Solution 135 All Problems Are Not Created Equal 136 Engaging with an Expert 136 Select a Behavior and Model Around a Concrete Scenario 137 Collaborate with the Domain Expert on the Most Interesting Parts 137 Evolve UL to Remove Ambiguity 138 Throw Away Your First Model, and Your Second 138 Implement the Model in Code 139 Creating a Domain Model 139 Keep the Solution Simple and Your Code Boring 139 Carve Out an Area of Safety 140 Integrate the Model Early and Often 140 Nontechnical Refactoring 140 Decompose Your Solution Space 140 Rinse and Repeat 141 Exploration and Experimentation 142 Challenge Your Assumptions 142 Modeling Is a Continuous Activity 142 There Are No Wrong Models 142 Supple Code Aids Discovery 143 Making the Implicit Explicit 143 Tackling Ambiguity 144 Give Things a Name 145 A Problem Solver First, A Technologist Second 146 Don’t Solve All the Problems 146 How Do I Know That I Am Doing It Right? 146 Good Is Good Enough 147 Practice, Practice, Practice 147 The Salient Points 147 PART II: STRATEGIC PATTERNS: COMMUNICATING BETWEEN BOUNDED CONTEXTS CHAPTER 11: INTRODUCTION TO BOUNDED CONTEXT INTEGRATION 151 How to Integrate Bounded Contexts 152 Bounded Contexts Are Autonomous 153 The Challenges of Integrating Bounded Contexts at the Code Level 153 Multiple Bounded Contexts Exist within a Solution 153 Namespaces or Projects to Keep Bounded Contexts Separate 154 Integrating via the Database 155 Multiple Teams Working in a Single Codebase 156 Models Blur 156 Use Physical Boundaries to Enforce Clean Models 157 Integrating with Legacy Systems 158 Bubble Context 158 Autonomous Bubble Context 158 Exposing Legacy Systems as Services 160 Integrating Distributed Bounded Contexts 161 Integration Strategies for Distributed Bounded Contexts 161 Database Integration 162 Flat File Integration 163 RPC 164 Messaging 165 REST 165 The Challenges of DDD with Distributed Systems 165 The Problem with RPC 166 RPC Is Harder to Make Resilient 167 RPC Costs More to Scale 167 RPC Involves Tight Coupling 168 Distributed Transactions Hurt Scalability and Reliability 169 Bounded Contexts Don’t Have to Be Consistent with Each Other 169 Eventual Consistency 169 Event‐Driven Reactive DDD 170 Demonstrating the Resilience and Scalability of Reactive Solutions 171 Challenges and Trade‐Offs of Asynchronous Messaging 173 Is RPC Still Relevant? 173 SOA and Reactive DDD 174 View Your Bounded Contexts as SOA Services 175 Decompose Bounded Contexts into Business Components 175 Decompose Business Components into Components 176 Going Even Further with Micro Service Architecture 178 The Salient Points 180 CHAPTER 12: INTEGRATING VIA MESSAGING 181 Messaging Fundamentals 182 Message Bus 182 Reliable Messaging 184 Store‐and‐Forward 184 Commands and Events 185 Eventual Consistency 186 Building an E‐Commerce Application with NServiceBus 186 Designing the System 187 Domain‐Driven Design 187 Containers Diagrams 188 Evolutionary Architecture 191 Sending Commands from a Web Application 192 Creating a Web Application to Send Messages with NServiceBus 192 Sending Commands 197 Handling Commands and Publishing Events 200 Creating an NServiceBus Server to Handle Commands 200 Configuring the Solution for Testing and Debugging 201 Publishing Events 204 Subscribing to Events 206 Making External HTTP Calls Reliable with Messaging Gateways 208 Messaging Gateways Improve Fault Tolerance 208 Implementing a Messaging Gateway 209 Controlling Message Retries 212 Eventual Consistency in Practice 215 Dealing with Inconsistency 215 Rolling Forward into New States 215 Bounded Contexts Store All the Data They Need Locally 216 Storage Is Cheap—Keep a Local Copy 217 Common Data Duplication Concerns 223 Pulling It All Together in the UI 224 Business Components Need Their Own APIs 225 Be Wary of Server‐Side Orchestration 226 UI Composition with AJAX Data 226 UI Composition with AJAX HTML 226 Sharing Your APIs with the Outside World 227 Maintaining a Messaging Application 227 Message Versioning 228 Backward‐Compatible Message Versioning 228 Handling Versioning with NServiceBus’s Polymorphic Handlers 229 Monitoring and Scaling 233 Monitoring Errors 233 Monitoring SLAs 234 Scaling Out 235 Integrating a Bounded Context with Mass Transit 235 Messaging Bridge 236 Mass Transit 236 Installing and Configuring Mass Transit 236 Declaring Messages for Use by Mass Transit 238 Creating a Message Handler 239 Subscribing to Events 239 Linking the Systems with a Messaging Bridge 240 Publishing Events 242 Testing It Out 243 Where to Learn More about Mass Transit 243 The Salient Points 243 CHAPTER 13: INTEGRATING VIA HTTP WITH RPC AND REST 245 Why Prefer HTTP? 247 No Platform Coupling 247 Everyone Understands HTTP 247 Lots of Mature Tooling and Libraries 247 Dogfooding Your APIs 247 RPC 248 Implementing RPC over HTTP 248 SOAP 249 Plain XML or JSON: The Modern Approach to RPC 259 Choosing a Flavor of RPC 263 REST 264 Demystifying REST 264 Resources 264 Hypermedia 265 Statelessness 265 REST Fully Embraces HTTP 266 What REST Is Not 267 REST for Bounded Context Integration 268 Designing for REST 268 Building Event‐Driven REST Systems with ASP.NET Web API 273 Maintaining REST Applications 303 Versioning 303 Monitoring and Metrics 303 Drawbacks with REST for Bounded Context Integration 304 Less Fault Tolerance Out of the Box 304 Eventual Consistency 304 The Salient Points 305 PART III: TACTICAL PATTERNS: CREATING EFFECTIVE DOMAIN MODELS CHAPTER 14: INTRODUCING THE DOMAIN MODELING BUILDING BLOCKS 309 Tactical Patterns 310 Patterns to Model Your Domain 310 Entities 310 Value Objects 314 Domain Services 317 Modules 318 Lifecycle Patterns 318 Aggregates 318 Factories 322 Repositories 323 Emerging Patterns 324 Domain Events 324 Event Sourcing 326 The Salient Points 327 CHAPTER 15: VALUE OBJECTS 329 When to Use a Value Object 330 Representing a Descriptive, Identity‐Less Concept 330 Enhancing Explicitness 331 Defining Characteristics 333 Identity‐Less 333 Attribute‐Based Equality 333 Behavior‐Rich 337 Cohesive 337 Immutable 337 Combinable 339 Self‐Validating 341 Testable 344 Common Modeling Patterns 345 Static Factory Methods 345 Micro Types (Also Known as Tiny Types) 347 Collection Aversion 349 Persistence 35 NoSQL 352 SQL 353 Flat Denormalization 353 Normalizing into Separate Tables 357 The Salient Points 359 CHAPTER 16: ENTITIES 36 Understanding Entities 362 Domain Concepts with Identity and Continuity 362 Context‐Dependent 363 Implementing Entities 363 Assigning Identifiers 363 Natural Keys 363 Arbitrarily Generated IDs 364 Datastore‐Generated IDs 368 Pushing Behavior into Value Objects and Domain Services 369 Validating and Enforcing Invariants 371 Focusing on Behavior, Not Data 374 Avoiding the “Model the Real‐World” Fallacy 377 Designing for Distribution 378 Common Entity Modeling Principles and Patterns 380 Implementing Validation and Invariants with Specifications 380 Avoid the State Pattern; Use Explicit Modeling 382 Avoiding Getters and Setters with the Memento Pattern 385 Favor Hidden‐Side‐Effect‐Free Functions 386 The Salient Points 388 CHAPTER 17: DOMAIN SERVICES 389 Understanding Domain Services 390 When to Use a Domain Service 390 Encapsulating Business Policies and Processes 390 Representing Contracts 394 Anatomy of a Domain Service 395 Avoiding Anemic Domain Models 395 Contrasting with Application Services 396 Utilizing Domain Services 397 In the Service Layer 397 In the Domain 398 Manually Wiring Up 399 Using Dependency Injection 400 Using a Service Locator 400 Applying Double Dispatch 401 Decoupling with Domain Events 402 Should Entities Even Know About Domain Services? 403 The Salient Points 403 CHAPTER 18: DOMAIN EVENTS 405 Essence of the Domain Events Pattern 406 Important Domain Occurrences That Have Already Happened 406 Reacting to Events 407 Optional Asynchrony 407 Internal vs External Events 408 Event Handling Actions 409 Invoke Domain Logic 409 Invoke Application Logic 410 Domain Events’ Implementation Patterns 410 Use the .Net Framework’s Events Model 410 Use an In‐Memory Bus 412 Udi Dahan’s Static DomainEvents Class 415 Handling Threading Issues 417 Avoid a Static Class by Using Method Injection 418 Return Domain Events 419 Use an IoC Container as an Event Dispatcher 421 Testing Domain Events 422 Unit Testing 422 Application Service Layer Testing 424 The Salient Points 425 CHAPTER 19: AGGREGATES 427 Managing Complex Object Graphs 428 Favoring a Single Traversal Direction 428 Qualifying Associations 430 Preferring IDs Over Object References 431 Aggregates 434 Design Around Domain Invariants 435 Higher Level of Domain Abstraction 435 Consistency Boundaries 435 Transactional Consistency Internally 436 Eventual Consistency Externally 439 Special Cases 440 Favor Smaller Aggregates 441 Large Aggregates Can Degrade Performance 441 Large Aggregates Are More Susceptible to Concurrency Conflicts 442 Large Aggregates May Not Scale Well 442 Defining Aggregate Boundaries 442 eBidder: The Online Auction Case Study 443 Aligning with Invariants 444 Aligning with Transactions and Consistency 446 Ignoring User Interface Influences 448 Avoiding Dumb Collections and Containers 448 Don’t Focus on HAS‐A Relationships 449 Refactoring to Aggregates 449 Satisfying Business Use Cases—Not Real Life 449 Implementing Aggregates 450 Selecting an Aggregate Root 450 Exposing Behavioral Interfaces 452 Protecting Internal State 453 Allowing Only Roots to Have Global Identity 454 Referencing Other Aggregates 454 Nothing Outside An Aggregate’s Boundary May Hold a Reference to Anything Inside 455 The Aggregate Root Can Hand Out Transient References to the Internal Domain Objects 456 Objects within the Aggregate Can Hold References to Other Aggregate Roots 456 Implementing Persistence 458 Access to Domain Objects for Reading Can Be at the Database Level 460 A Delete Operation Must Remove Everything within the Aggregate Boundary at Once 461 Avoiding Lazy Loading 461 Implementing Transactional Consistency 462 Implementing Eventual Consistency 463 Rules That Span Multiple Aggregates 463 Asynchronous Eventual Consistency 464 Implementing Concurrency 465 The Salient Points 468 CHAPTER 20: FACTORIES 469 The Role of a Factory 469 Separating Use from Construction 470 Encapsulating Internals 470 Hiding Decisions on Creation Type 472 Factory Methods on Aggregates 474 Factories for Reconstitution 475 Use Factories Pragmatically 477 The Salient Points 477 CHAPTER 21: REPOSITORIES 479 Repositories 479 A Misunderstood Pattern 481 Is the Repository an Antipattern? 481 The Difference between a Domain Model and a Persistence Model 482 The Generic Repository 483 Aggregate Persistence Strategies 486 Using a Persistence Framework That Can Map the Domain Model to the Data Model without Compromise 486 Using a Persistence Framework That Cannot Map the Domain Model Directly without Compromise 487 Public Getters and Setters 487 Using the Memento Pattern 488 Event Streams 49 Be Pragmatic 491 A Repository Is an Explicit Contract 492 Transaction Management and Units of Work 493 To Save or Not To Save 497 Persistence Frameworks That Track Domain Object Changes 497 Having to Explicitly Save Changes to Aggregates 498 The Repository as an Anticorruption Layer 499 Other Responsibilities of a Repository 500 Entity ID Generation 500 Collection Summaries 502 Concurrency 503 Audit Trails 506 Repository Antipatterns 506 Antipatterns: Don’t Support Ad Hoc Queries 506 Antipatterns: Lazy Loading Is Design Smell 507 Antipatterns: Don’t Use Repositories for Reporting Needs 507 Repository Implementations 508 Persistence Framework Can Map Domain Model to Data Model without Compromise 509 NHibernate Example 509 RavenDB Example 543 Persistence Framework Cannot Map Domain Model Directly without Compromise 557 Entity Framework Example 558 Micro ORM Example 577 The Salient Points 593 CHAPTER 22: EVENT SOURCING 595 The Limitations of Storing State as a Snapshot 596 Gaining Competitive Advantage by Storing State as a Stream of Events 597 Temporal Queries 597 Projections 599 Snapshots 599 Event‐Sourced Aggregates 600 Structuring 600 Adding Event‐Sourcing Capabilities 601 Exposing Expressive Domain‐Focused APIs 602 Adding Snapshot Support 604 Persisting and Rehydrating 605 Creating an Event-Sourcing Repository 605 Adding Snapshot Persistence and Reloading 607 Handling Concurrency 609 Testing 610 Building an Event Store 611 Designing a Storage Format 612 Creating Event Streams 614 Appending to Event Streams 614 Querying Event Streams 615 Adding Snapshot Support 616 Managing Concurrency 618 A SQL Server‐Based Event Store 621 Choosing a Schema 621 Creating a Stream 622 Saving Events 623 Loading Events from a Stream 624 Snapshots 625 Is Building Your Own Event Store a Good Idea? 627 Using the Purpose‐Built Event Store 627 Installing Greg Young’s Event Store 628 Using the C# Client Library 627 Running Temporal Queries 632 Querying a Single Stream 632 Querying Multiple Streams 634 Creating Projections 635 CQRS with Event Sourcing 637 Using Projections to Create View Caches 638 CQRS and Event Sourcing Synergy 638 Event Streams as Queues 639 No Two‐Phase Commits 639 Recapping the Benefits of Event Sourcing 639 Competitive Business Advantage 639 Expressive Behavior‐Focused Aggregates 639 Simplified Persistence 640 Superior Debugging 640 Weighing the Costs of Event Sourcing 640 Versioning 640 New Concepts to Learn and Skills to Hone 640 New Technologies to Learn and Master 641 Greater Data Storage Requirements 641 Additional Learning Resources 641 The Salient Points 641 PART IV: DESIGN PATTERNS FOR EFFECTIVE APPLICATIONS CHAPTER 23: ARCHITECTING APPLICATION USER INTERFACES 645 Design Considerations 646 Owned UIs versus Composed UIs 646 Autonomous 646 Authoritative 647 Some Help Deciding 648 HTML APIs versus Data APIs 649 Client versus Server‐Side Aggregation/Coordination 649 Example 1: An HTML API‐Based, Server‐Side UI for Nondistributed Bounded Contexts 651 Example 2: A Data API‐Based, Client‐Side UI for Distributed Bounded Contexts 658 The Salient Points 667 CHAPTER 24: CQRS: AN ARCHITECTURE OF A BOUNDED CONTEXT 669 The Challenges of Maintaining a Single Model for Two Contexts 670 A Better Architecture for Complex Bounded Contexts 670 The Command Side: Business Tasks 672 Explicitly Modeling Intent 672 A Model Free from Presentational Distractions 674 Handling a Business Request 675 The Query Side: Domain Reporting 676 Reports Mapped Directly to the Data Model 676 Materialized Views Built from Domain Events 678 The Misconceptions of CQRS 679 CQRS Is Hard 679 CQRS Is Eventually Consistent 679 Your Models Need to Be Event Sourced 680 Commands Should Be Asynchronous 680 CQRS Only Works with Messaging Systems 680 You Need to Use Domain Events with CQRS 680 Patterns to Enable Your Application to Scale 680 Scaling the Read Side: An Eventually Consistent Read Model 681 The Impact to the User Experience 682 Use the Read Model to Consolidate Many Bounded Contexts 682 Using a Reporting Database or a Caching Layer 682 Scaling the Write Side: Using Asynchronous Commands 683 Command Validation 683 Impact to the User Experience 684 Scaling It All 684 The Salient Points 685 CHAPTER 25: COMMANDS: APPLICATION SERVICE PATTERNS FOR PROCESSING BUSINESS USE CASES 687 Differentiating Application Logic and Domain Logic 689 Application Logic 689 Infrastructural Concerns 690 Coordinating Full Business Use Cases 698 Application Services and Framework Integration 698 Domain Logic from an Application Service’s Perspective 700 Application Service Patterns 700 Command Processor 701 Publish/Subscribe 704 Request/Reply Pattern 706 async/await 708 Testing Application Services 709 Use Domain Terminology 709 Test as Much Functionality as Possible 710 The Salient Points 712 CHAPTER 26: QUERIES: DOMAIN REPORTING 713 Domain Reporting within a Bounded Context 714 Deriving Reports from Domain Objects 714 Using Simple Mappings 714 Using the Mediator Pattern 718 Going Directly to the Datastore 720 Querying a Datastore 721 Reading Denormalized View Caches 724 Building Projections from Event Streams 726 Setting Up ES for Projections 727 Creating Reporting Projections 728 Counting the Number of Events in a Stream 729 Creating As Many Streams As Required 729 Building a Report from Streams and Projections 730 Domain Reporting Across Bounded Contexts 733 Composed UI 733 Separate Reporting Context 734 The Salient Points 736 INDEX 737

Autorenportrait

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.

Back cover copy

Build solutions for complex business problems more effectively with Domain-Driven Design This book distills the ideas and theories of the Domain-Driven Design (DDD) philosophy into a practical playbook that you can leverage to simplify application development for complex problem domains. A focus is placed on the principles and practices of decomposing a complex problem space as well as the implementation patterns and best practices for shaping a maintainable solution space. You will learn how to build effective domain models through the use of tactical patterns and how to retain their integrity by applying the strategic patterns of DDD. Full end-to-end coding examples demonstrate techniques for integrating a decomposed and distributed solution space while coding best practices and patterns advise you on how to architect applications for maintenance and scale. <ul> <li>Offers a thorough introduction to the philosophy of DDD for professional developers</li> <li>Simplifies the theories of Domain-Driven Design into practical principles and practices</li> <li>Includes masses of code and examples of concepts in action that other books have only covered theoretically</li> <li>Covers the patterns of CQRS, Messaging, REST, Event Sourcing and Event-Driven Architectures</li> <li>Ideal for developers using Java, Ruby, and other languages who want to learn common DDD implementation patterns</li> <li>Code examples presented in C# demonstrating concepts that can be applied in any language</li> </ul> Wrox Professional guides are planned and written by working programmers to meet the real-world needs of programmers, developers, and IT professionals.Focused and relevant, they address the issues technology professionals face every day. They provide examples, practical solutions, and expert education in new technologies, all designed to help programmers do a better job.