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

Part III. Strategic Domain-Driven Transformation

In Part II, we looked at Domain-Driven Transformation both in the small (technically and tactically) and in terms of team organization. Now in this third part of the book, we will look at Domain-Driven Transformation in the larger context, i.e., at the decomposition of a legacy system. To do this, we want to understand the domain behind it so that we can then decompose it on the basis of the subdomains found.

In a sense, we have the opposite problem compared to building a new system on a greenﬁeld site.

If you want to develop new software on a greenﬁeld basis for an application area for which no specialized software yet exists, you have to ﬁnd out which steps in the users’ business processes—with paper and pencil, or with Word, Excel, and email—are really relevant and worth preserving. At this point, you will usually encounter process steps that can already be greatly simpliﬁed or even made superﬂuous without software, but even more so through the development of new software.

Software Development in the Brownﬁeld

If there is already legacy software that has been used and developed over the years, then you are more likely to see this phenomenon: business processes have shifted over the years because of one or more of the following reasons: