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

Overview

To prepare legacy software for the future, it's essential to modernize it. Domain-Driven Transformation provides an effective approach for transforming large legacy systems—either by breaking them into microservices or by converting them into maintainable modular monoliths.

In this guide, Carola Lilienthal and Henning Schwentner present their method, a comprehensive approach for transforming architecturally eroded software systems at the strategic, technical, and team organizational levels. You'll learn how to analyze business processes, break them down into bounded contexts, and apply domain-driven refactorings within Agile teams. Finally, this book offers guidance on designing the transformation process based on the current state of the existing architecture.

Packed with real-world examples and case-driven insights, you'll uncover the tools you need to build systems that scale, support business agility, and remain resilient over time.

Assess your system's modularity and architectural health with the Modularity Maturity Index (MMI)
Apply strategic and tactical domain-driven design (DDD) to manage complexity
Reorganize and align your teams with Team Topologies
Use EventStorming, domain storytelling, and Scenario Casting to clarify design
Refactor incrementally with patterns that reduce risk while delivering value