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

2 Distilling the Problem Domain

WHAT’S IN THIS CHAPTER?

The need for knowledge crunching
How collaboration can foster a shared understanding and a shared language
What a domain expert is and why the role is essential
Effective methods for gaining domain knowledge

Making sense of a complex problem domain in order to create a simple and useful model requires in-depth knowledge and deep insight that can only be gained through collaboration with the people that understand the domain inside and out. Continuous experimentation and exploration in the design of a model is where the power of DDD is realized. Only through collaboration and a shared understanding of the problem domain can you effectively design a model to solve the challenges of the business that will be supple enough to adapt as new requirements surface.

This chapter introduces methods to facilitate the distilling of domain knowledge in order to better understand the problem domain, which will enable you to build an effective domain model. Methods to extract important information on the behaviors of an application along with techniques to discover deep insights within the problem domain are also presented.

Knowledge Crunching and Collaboration

Complex problem domains will contain a wealth of information, some of which will not be applicable to solving the problem at hand and will only act to distract from the real focus of your modelling efforts. Knowledge crunching is the art of distilling relevant information from ...