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

About the Authors

Carola Lilienthal is CEO of WPS – Workplace Solutions GmbH in Hamburg, where she is responsible for the ﬁeld of software architecture. She received her master’s degree in computer science from the University of Hamburg in 1995, where she wrote her doctoral thesis on the complexity of software architectures. Since 2003, she has been analyzing the architecture of software systems internationally on behalf of her customers and advising development teams on how they can improve the sustainability of their software systems. In total, Carola and her team have analyzed over 300 software systems with between 30,000 and 15 million LOC in Java, C++, C#, ABAP, PHP, and TypeScript.

Carola is the author of Sustainable Software Architecture (dpunkt). She is particularly interested in the education of software architects and developers, which is why she is an active member of iSAQB, the International Software Architecture Qualiﬁcation Board, and regularly shares her knowledge from over 25 years of software development at conferences, in articles, and at training courses.

Henning Schwentner is a programmer who has been into computers ever since he got an Amiga 500 in the early ’90s. He was lucky enough to turn this passion into a profession and works as a coder, coach, and consultant at WPS – Workplace Solutions. He helps teams bring structure to their existing software or build new systems with a sustainable architecture from scratch.

Henning is the author of Domain Storytelling ...