book

Patterns, Principles, and Practices of Domain-Driven Design

by Scott Millett, Nick Tune

May 2015

Intermediate to advanced

792 pages

22h 32m

English

Wrox

Read now

Unlock full access

Overview of the Book and TechnologyHow This Book Is OrganizedWho Should Read This BookSource CodeErratap2p.wrox.comSummary
The Challenges of Creating Software for Complex Problem DomainsHow the Patterns of Domain-Driven Design Manage ComplexityThe Practices and Principles of Domain-Driven DesignPopular Misconceptions of Domain-Driven DesignThe Salient Points
Knowledge Crunching and CollaborationGaining Domain Insight with Domain ExpertsPatterns for Effective Knowledge CrunchingLook For Existing ModelsThe Salient Points
Why Decompose a Problem Domain?How to Capture the Essence of the ProblemHow to Focus on the Core ProblemHow Subdomains Shape a SolutionNot All Parts of a System Will Be Well DesignedWhat If You Have No Core Domain?The Salient Points
What Is a Domain Model?Model-Driven DesignUsing a Ubiquitous Language to Bind the Analysis to the Code ModelCollaborating on a Ubiquitous LanguageHow to Create Effective Domain ModelsWhen to Apply Model-Driven DesignThe Salient Points
The Domain LayerDomain Model Implementation PatternsThe Salient Points
The Challenges of a Single ModelUse Bounded Contexts to Divide and Conquer a Large ModelImplementing Bounded ContextsThe Salient Points
A Reality MapRecognising the Relationships between Bounded ContextsCommunicating the Context MapThe Strategic Importance of Context MapsThe Salient Points
Application ArchitectureApplication ServicesApplication ClientsThe Salient Points

Overemphasizing the Importance of Tactical PatternsMissing the Real Value of DDD: Collaboration, Communication, and ContextSpending Too Much Time on What’s Not ImportantMaking Simple Problems ComplexUnderestimating the Cost of Applying DDDThe Salient Points
Selling DDDApplying the Principles of DDDExploration and ExperimentationMaking the Implicit ExplicitA Problem Solver First, A Technologist SecondHow Do I Know That I Am Doing It Right?The Salient Points
How to Integrate Bounded ContextsIntegrating Distributed Bounded ContextsThe Challenges of DDD with Distributed SystemsSOA and Reactive DDDThe Salient Points
Messaging FundamentalsBuilding an E-Commerce Application with NServiceBusMaintaining a Messaging ApplicationIntegrating a Bounded Context with Mass TransitThe Salient Points
Why Prefer HTTP?RPCRESTThe Salient Points
Tactical PatternsPatterns to Model Your DomainLifeCycle PatternsEmerging PatternsThe Salient Points
When to Use a Value ObjectDefining CharacteristicsCommon Modeling PatternsPersistenceThe Salient Points
Understanding EntitiesImplementing EntitiesCommon Entity Modeling Principles and PatternsThe Salient Points
Understanding Domain ServicesUtilizing Domain ServicesThe Salient Points
Essence of the Domain Events PatternEvent Handling ActionsDomain Events’ Implementation PatternsTesting Domain EventsThe Salient Points
Managing Complex Object GraphsAggregatesDefining Aggregate BoundariesImplementing AggregatesThe Salient Points
The Role of a FactoryThe Salient Points
RepositoriesA Misunderstood PatternAggregate Persistence StrategiesA Repository Is an Explicit ContractTransaction Management and Units of WorkTo Save or Not To SaveThe Repository as an Anticorruption LayerOther Responsibilities of a RepositoryRepository AntipatternsRepository ImplementationsThe Salient Points
The Limitations of Storing State as a SnapshotGaining Competitive Advantage by Storing State as a Stream of EventsEvent-Sourced AggregatesBuilding an Event StoreUsing the Purpose-Built Event StoreCQRS with Event SourcingRecapping the Benefits of Event SourcingWeighing the Costs of Event SourcingAdditional Learning ResourcesThe Salient Points
Design ConsiderationsExample 1: An HTML API-Based, Server-Side UI for Nondistributed Bounded ContextsExample 2: A Data API-Based, Client-Side UI for Distributed Bounded ContextsThe Salient Points
The Challenges of Maintaining a Single Model for Two ContextsA Better Architecture for Complex Bounded ContextsThe Command Side: Business TasksThe Query Side: Domain ReportingThe Misconceptions of CQRSPatterns to Enable Your Application to ScaleThe Salient Points
Differentiating Application Logic and Domain LogicApplication Service PatternsTesting Application ServicesThe Salient Points
Domain Reporting Within a Bounded ContextDomain Reporting Across Bounded ContextsThe Salient Points

Content preview from Patterns, Principles, and Practices of Domain-Driven Design

22 Event Sourcing

WHAT’S IN THIS CHAPTER?

An introduction to event sourcing and the problems it solves
Guidance and examples for building event-sourced domain models
How to build an Event Store
Examples of building Event Stores on top of RavenDB and SQL Server
Examples of using Greg Young’s Event Store
A discussion of how CQRS synergizes with event sourcing
A list of trade-offs to help you understand when event sourcing is a good choice and when you should avoid it

Wrox.com Code Downloads for This Chapter

The wrox.com code downloads for this chapter are found at www.wrox.com/go/domaindrivendesign on the Download Code tab. The code is in the Chapter 22 download and individually named according to the names throughout the chapter.

Bringing a competitive business advantage and exciting technical challenges, it’s clear why a storage mechanism called event sourcing has gained a lot of popularity in recent years. Because a full history of activity is stored, event sourcing allows businesses to deeply understand many aspects of their data, including detailed behavior of their customers. With this historical information, new and novel queries can be asked that inform product development, marketing strategies, and other business decisions. Using event sourcing, you can determine what the state of the system looked like at any given point in time and how it reached any of those states. For many domains, this is a game-changing capability.

Many systems today store only the current state ...