book

Learning Domain-Driven Design

by Vlad Khononov

October 2021

Intermediate to advanced

342 pages

8h 32m

English

O'Reilly Media, Inc.

Book available

Read now

Unlock full access

Includes

Includes Quizzes

Why I Wrote This BookWho Should Read This BookNavigating the BookExample Domain: WolfDeskConventions Used in This BookUsing Code ExamplesO’Reilly Online LearningHow to Contact UsAcknowledgments
What Is a Business Domain?What Is a Subdomain?Types of SubdomainsComparing SubdomainsIdentifying Subdomain BoundariesDomain Analysis ExamplesGigmasterBusVNextWho Are the Domain Experts?ConclusionExercises
Business ProblemsKnowledge DiscoveryCommunicationWhat Is a Ubiquitous Language?Language of the BusinessScenariosConsistencyModel of the Business DomainWhat Is a Model?Effective ModelingModeling the Business DomainContinuous EffortToolsChallengesConclusionExercises
Inconsistent ModelsWhat Is a Bounded Context?Model BoundariesUbiquitous Language RefinedScope of a Bounded ContextBounded Contexts Versus SubdomainsSubdomainsBounded ContextsThe Interplay Between Subdomains and Bounded ContextsBoundariesPhysical BoundariesOwnership BoundariesBounded Contexts in Real LifeSemantic DomainsScienceBuying a Refrigerator ConclusionExercises
CooperationPartnershipShared KernelCustomer–SupplierConformistAnticorruption LayerOpen-Host ServiceSeparate WaysCommunication IssuesGeneric SubdomainsModel DifferencesContext MapMaintenance LimitationsConclusionExercises
Transaction ScriptImplementationIt’s Not That Easy!When to Use Transaction ScriptActive RecordImplementationWhen to Use Active RecordBe PragmaticConclusionExercises

HistoryDomain ModelImplementationBuilding BlocksManaging Complexity ConclusionExercises
Event SourcingSearchAnalysisSource of TruthEvent StoreEvent-Sourced Domain ModelAdvantagesDisadvantagesFrequently Asked QuestionsPerformanceDeleting DataWhy Can’t I Just…?ConclusionExercises
Business Logic Versus Architectural PatternsLayered ArchitecturePresentation LayerBusiness Logic LayerData Access LayerCommunication Between LayersVariationWhen to Use Layered ArchitecturePorts & AdaptersTerminologyDependency Inversion PrincipleIntegration of Infrastructural ComponentsVariantsWhen to Use Ports & AdaptersCommand-Query Responsibility SegregationPolyglot ModelingImplementationProjecting Read ModelsChallengesModel SegregationWhen to Use CQRSScopeConclusionExercises
Model TranslationStateless Model TranslationStateful Model TranslationIntegrating Aggregates Outbox SagaProcess ManagerConclusionExercises
HeuristicBounded ContextsBusiness Logic Implementation PatternsArchitectural PatternsTesting StrategyTesting PyramidTesting DiamondReversed Testing PyramidTactical Design Decision TreeConclusionExercises
Changes in DomainsCore to GenericGeneric to CoreSupporting to GenericSupporting to CoreCore to SupportingGeneric to SupportingStrategic Design ConcernsTactical Design ConcernsTransaction Script to Active RecordActive Record to Domain ModelDomain Model to Event-Sourced Domain ModelGenerating Past TransitionsModeling Migration EventsOrganizational ChangesPartnership to Customer–SupplierCustomer–Supplier to Separate WaysDomain KnowledgeGrowthSubdomainsBounded ContextsAggregatesConclusionExercises
What Is EventStorming?Who Should Participate in EventStorming?What Do You Need for EventStorming?The EventStorming ProcessStep 1: Unstructured ExplorationStep 2: TimelinesStep 3: Pain PointsStep 4: Pivotal EventsStep 5: CommandsStep 6: PoliciesStep 7: Read ModelsStep 8: External SystemsStep 9: AggregatesStep 10: Bounded ContextsVariantsWhen to Use EventStormingFacilitation TipsWatch the DynamicsRemote EventStormingConclusionExercises
Strategic AnalysisUnderstand the Business DomainExplore the Current DesignModernization StrategyStrategic ModernizationTactical ModernizationCultivate a Ubiquitous LanguagePragmatic Domain-Driven DesignSelling Domain-Driven DesignUndercover Domain-Driven DesignConclusionExercises
What Is a Service?What Is a Microservice?Method as a Service: Perfect Microservices?Design GoalSystem ComplexityMicroservices as Deep ServicesMicroservices as Deep ModulesDomain-Driven Design and Microservices’ BoundariesBounded ContextsAggregatesSubdomainsCompressing Microservices’ Public InterfacesOpen-Host ServiceAnticorruption LayerConclusionExercises
Event-Driven ArchitectureEventsEvents, Commands, and MessagesStructureTypes of EventsDesigning Event-Driven IntegrationDistributed Big Ball of MudTemporal CouplingFunctional CouplingImplementation CouplingRefactoring the Event-Driven IntegrationEvent-Driven Design HeuristicsConclusionExercises
Analytical Data Model Versus Transactional Data ModelFact TableDimension TableAnalytical ModelsAnalytical Data Management PlatformsData WarehouseData LakeChallenges of Data Warehouse and Data Lake ArchitecturesData MeshDecompose Data Around DomainsData as a ProductEnable AutonomyBuild an EcosystemCombining Data Mesh and Domain-Driven DesignConclusionExercises
ProblemSolutionImplementationFurther ReadingAdvanced Domain-Driven DesignArchitectural and Integration PatternsModernization of Legacy SystemsEventStormingConclusion
Five Bounded ContextsBusiness DomainBounded Context #1: MarketingBounded Context #2: CRMBounded Context #3: Event CrunchersBounded Context #4: BonusesBounded Context #5: The Marketing HubDiscussionUbiquitous LanguageSubdomainsBoundaries of Bounded ContextsConclusion
Chapter 1Chapter 2Chapter 3Chapter 4Chapter 5Chapter 6Chapter 7Chapter 8Chapter 9Chapter 10Chapter 11Chapter 12Chapter 13Chapter 14Chapter 15Chapter 16

Content preview from Learning Domain-Driven Design

Part I. Strategic Design

There is no sense in talking about the solution before we agree on the problem, and no sense talking about the implementation steps before we agree on the solution.

Efrat Goldratt-Ashlag¹

The domain-driven design (DDD) methodology can be divided into two main parts: strategic design and tactical design. The strategic aspect of DDD deals with answering the questions of “what?” and “why?”—what software we are building and why we are building it. The tactical part is all about the “how”—how each component is implemented.

We will begin our journey by exploring domain-driven design patterns and principles of strategic design:

In Chapter 1, you will learn to analyze a company’s business strategy: what value it provides to its consumers and how it competes with other companies in the industry. We will identify finer-grained business building blocks, evaluate their strategic value, and analyze how they affect different software design decisions.
Chapter 2 introduces domain-driven design’s essential practice for gaining an understanding of the business domain: the ubiquitous language. You will learn how to cultivate a ubiquitous language and use it to foster a shared understanding among all project-related stakeholders.
Chapter 3 discusses another domain-driven design core tool: the bounded context pattern. You will learn why this tool is essential for cultivating a ubiquitous language and how to use it to transform discovered knowledge into a model of ...