book

Domain-Driven Transformation

by Carola Lilienthal, Henning Schwentner

November 2025

Intermediate to advanced

464 pages

11h 25m

English

O'Reilly Media, Inc.

Book available

Read now

Unlock full access

Structure of This BookAI-Aided TransformationConventions Used in This BookO’Reilly Online LearningHow to Contact UsAcknowledgments
Example: A Legacy System in a Container PortDomain RediscoveryDetermining Target ArchitectureComparing Actual Architecture with Target ArchitecturePrioritization and Implementation of the TransformationWhat Has Just Happened?The MethodPaths Through Domain-Driven TransformationSummary
Origin of Complexity: Problem and Solution SpaceType of Complexity: Essential Versus AccidentalSources of Accidental ComplexityDecision Areas of Software ArchitectureDealing with Essential and Accidental ComplexityComplexity in Legacy SystemsThe Fundamental MethodsWhat’s Next?
DDD Concepts Against ComplexityDDD and the Business DomainUbiquitous LanguageStrategic Design on the Business SideCategorizing Subdomains—What Is Core?DDD and the Software SolutionStrategic Design in the SoftwareContext MappingBubble ContextThe Domain ModelThe Layered Architecture in DDDTactical DesignDomain EventsSummary
Modeling Tools and the Model MonopolyCollaborative Modeling Methods for TransformationBringing the Right People TogetherFundamental Concepts of Collaborative ModelingCollaborative Modeling and DDDDomain StorytellingOne Picture—One StoryDrawing BoundariesScope Factors for Domain StoriesFinding the Domain ModelOutlookEventStormingExploring with Big Picture EventStormingChaotic ExplorationEnforcing the TimelinePeople and SystemsExplicit WalkthroughValue-Added StepsDrawing BoundariesThe Color CodingDeeper into the Details: Software Design EventStormingFinding the Domain ModelOther Formats and OutlookScenario CastingHow Does the Method Work?The Core IdeaWorkshop Flow: From Exploration to ImplementationIntroducing a Case Study: Green Urban SupplierStep 1: BrainstormingStep 2: FocusingStep 3: AssemblingWhat’s Next in the Scenario-Based Approach?The Second Round of Scenario CastingOutlookWhich Method to Use When?Collaborative Modeling RemoteCollaboration Modeling and AIOther Collaborative Modeling MethodsSummary
Architecture Documentation with the C4 ModelLevel 1: ContextLevel 2: ContainersLevel 3: ComponentsLevel 4: CodeModularityCohesion and CouplingCohesion and Coupling in DDDCohesion and Coupling in the DomainBig Ball of MudAt the Class LevelAt the Architecture LevelWhere Does the Big Ball of Mud Come From?Coupling and ReuseArchitectural Styles for Legacy SystemsMonolithMicroservicesFrom Monolith to MicroservicesThe Good Old Layered ArchitectureInside-Outside Architectures: Hexagonal/Ports & Adapters, Onion, Clean, and MoreDiﬀerent Styles Together—Explicit ArchitectureInside-Outside Architectures and Tactical DDDSoftware Architecture HamburgerService-Oriented ArchitecturesSelf-Contained SystemsFrom IT Landscapes to SOA and Back AgainThe Modularity Maturity Index: Where Do You Stand?Modularity in the MMIHierarchy in the MMIPattern Consistency in the MMICalculation of the MMISummary
Replacement—Big BangReplacement—Step-by-StepReshapingSummary

Updating the Integrated Development EnvironmentAutomating Build and DeploymentUpdating Software DependenciesUpdating Libraries and FrameworksUpdating the Programming LanguageResolving Compiler and IDE WarningsIncrease Test Coverage When Fixing BugsThe Scout Rule (Formerly Known as the Boy Scout Rule)Diﬀerent Kinds of TestsCleaning Up the Code as You GoRefactoringBreaking DependenciesImproving Internal Structure Using MetricsImproving Error RobustnessBuild Robustness Against NullImprove the Use of ExceptionsIntroduce Design by ContractSummaryWhere Do You Stand?—Made Easy
Separating Business Source Code and Technical Source CodeIncreasing CohesionEnrich Modeling with Domain KnowledgeUtilize Value ObjectsIntroduce Design by ContractMake the Identity of Entities ExplicitReduce CouplingBreak Cycles and DependenciesIntroduce ID References at Aggregate BoundariesReduce Inheritance in Business Source CodeThe Liskov Substitution PrincipleDocumenting Architecture in CodeDoes the AI have Knowledge About My Domain?SummaryWhere Do You Stand?—Made Easy
Software as a Sociotechnical SystemHorizontal Architecture/Team OrganizationVertical Architecture/Team OrganizationHow to Perform This Team Reorganization?Team TopologiesWorking in the FlowTypes of TopologiesTeam Interaction ModesTeam Evolution Over TimeArchitecture Modernization Enabling TeamsSummaryWhere Do You Stand?—Made Easy
Schematic Description of Step 1Challenge: Gathering the Right Domain ExpertsChallenge: Leading Domain Experts Back to the Actual DomainSubstep 1.1: Getting to Know the As-Is SituationSubstep 1.2: Extracting the Domain Knowledge (Puriﬁcation)Technique: Thought Experiment “Paper Process”Technique: Thought Experiment “Virtual Actors”Alternative: Modeling Pure in the First PlaceDistilling Ubiquitous LanguageSubstep 1.3: Optimizing the Business ProcessesSubstep 1.4: Finding Subdomains in the Business ProcessesIndicators for Subdomain BoundariesChallenge: Do Not Decompose by Work ItemsChallenge: Finding the Right SizeGoals of the Right SizeIndicators for the Right SizeDiscussing Decomposition with AISummary
Schematic Description of Step 2Substep 2.1: Creating a Context MapChallenge: Solution-Space Induced ContextsSubstep 2.2: Categorizing SubdomainsSubstep 2.3: Assigning Bounded Contexts to TeamsChallenge: Assigning Teams Often Means Shaping TeamsSubstep 2.4: Determining RelationshipsPutting It All TogetherSummary
Schematic Description of Step 3Substep 3.1: Identifying the Actual ArchitectureActual Architecture and AISubstep 3.2: Comparing the Target Context Map and the Source CodeChallenge: Unbounded ModelsDecomposition from Inside to OutsideChallenge: The Unbounded Domain ModelProblem Cause: Reusability MisunderstoodChallenge: The Unbounded Anemic Domain ModelChallenge: The Unbounded Data ModelChallenge: Decomposing the User InterfaceMonolithic UIUI in Context: MicrofrontendsSubstep 3.3: Compiling Refactorings and FindingsSummary
Schematic Description of Step 4Substep 4.1: Selecting the First Strategic RefactoringPattern: Start with a Supporting SubdomainPattern: Proceed with a Core DomainSubstep 4.2: Adding Tactical Refactorings to the Product Backlog (or Improvement Backlog)Substep 4.3: Planning Achievable Refactorings into the Sprint BacklogLet the Refactoring Pause Only in EmergenciesEstimating RefactoringsDomain-Driven Transformation with KanbanSubstep 4.4: Extracting ContextChallenge: Disentangling Business Logic in ServicesChallenge: Moving Local Data, Setters, and Getters into a ContextIdentity of EntitiesChallenge: Duplicating Data, Setters, and Getters into Multiple ContextsChallenge: Introducing Domain Events Between ServicesChallenge: Move Domain Logic Out of Services and into the Anemic Domain ModelPush Down Logic from Services into Anemic EntitiesChallenge: Disentangling the Data ModelChallenge: Selecting Findings at the Appropriate MomentChallenge: Keeping the StaminaSummary
Dimension 1: Workﬂow in the DomainDomain Pattern PipelineDomain Pattern BlackboardDomain Pattern DialogEvolution of Domains and the Patterns They FollowDimension 2: The Domain Model in the SoftwareCentral Domain Item Versus Diverse Domain ItemsForm-Based Domain ModelDimension 3: Shape of the DomainAge and Maturity of the DomainTangible Objects Domain Versus Fully Digitalized DomainRoom for TransformationSummary
Extract Bounded ContextMotivationMechanicsImplement Bounded Context from ScratchMotivationMechanics
Extract Specialized ServiceMotivationMechanicsExtract Specialized EntityMotivationMechanicsExtract Specialized Anemic EntityMotivationMechanicsExtract Specialized TableMotivationSchema Update MechanicsData-Migration MechanicsAccess Program Mechanics
Form Cross-Functional Team Out of Layer-Team MembersMotivationMechanicsForm Second Cross-Functional Team Out of Partly Layer-Team and First-Team MembersMotivationMechanicsForm Second Team Out of Only Layer-Team MembersMotivationMechanics
Enforce Ubiquitous LanguageMotivationMechanicsReplace Primitive with Value ObjectMotivationMechanicsHeal Entity AnemiaMotivationMechanicsReplace SetterMotivationMechanicsRemove SetterMotivationMechanicsMove Logic from Service to EntityMotivationMechanicsIntroduce ContractMotivationMechanicsSplit Active Record into Aggregate and RepositoryMotivationMechanicsSplit Repository into Interface and ImplementationMotivationMechanicsExtract Entity from Smart UIMotivationMechanicsExtract Service from Smart UIMotivationMechanics

Content preview from Domain-Driven Transformation

Appendix C. Tactical Refactorings That Support Strategic Refactorings

Strategic refactorings are still big and have to be divided into smaller steps. In this appendix we present these smaller steps—tactical refactorings that support the strategic ones. A supporting tactical refactoring is always carried out as part of a strategic refactoring.

When extracting a bounded context, you can encounter diﬀerent situations:

An anemic domain model. Then Extract Specialized Anemic Entity and Extract Specialized Service, can help you.
A domain model with rich behavior. This can be split with Extract Specialized Entity and with Extract Specialized Service.
A monolithic data model. Tackle it with Extract Specialized Table.

Extract Specialized Service

Also known as: Carve Specialized Anemic Service Out of Monolithic Service

A special case of Extract Class [Fowler 2019, p. 182]

Diagram illustrating the "Extract Class" refactoring pattern by splitting the "Monolease" class's "ContractService" functions into two separate classes, retaining "vote()" in "Monolease" and moving "calculateInstallment()" and "sign()" to "offering".

Motivation

As one step of Extract Bounded Context, you’ve found a domain service that has become too big. Its functionality belongs partly in the bounded context that is extracted. The decision has been made to split it.

Mechanics

Create an empty new class in the carved-out context.
Add an instance ﬁeld of type new class to the old class.
Copy the ﬁrst to-be-moved method to the new class with Move Method [Fowler 2019, p. 198].
Replace the method body in the old class with a forward to the method in ...