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

5 Domain Model Implementation Patterns

WHAT’S IN THIS CHAPTER?

The role of the domain layer in an application
Patterns to implement your domain model in code
How to select the right design pattern to represent your model

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 5 download and individually named according to the names throughout the chapter.

The focus of DDD is to manage complexity. As you have read, this is achieved by placing a model of the domain at the center of your software to fulfill the behaviors of your application. There are various patterns at your disposal to represent the model in code form. In Chapter 3, “Focusing on the Core Domain,” you were introduced to subdomains and the reality that more than one model may exist in large applications. However, not all models will be of equal complexity or importance. Some will contain complex domain logic, while others will simply be responsible for the management of data, therefore it is wise to choose the most appropriate design pattern to represent the model in code.

It is important to understand that there is no best practice when it comes to selecting a pattern to represent your domain logic. As long as you isolate domain logic from technical concerns you can implement Model-Driven Design and hence Domain-Driven Design.

This chapter presents the design patterns at your ...