Domain-Driven Transformation. Modernize Legacy Systems and Mitigate Risk Carola Lilienthal, Henning Schwentner

Dostępność produktu

Produkt nie został jeszcze oceniony pod kątem ułatwień dostępu lub nie podano żadnych informacji o ułatwieniach dostępu lub są one niewystarczające. Prawdopodobnie Wydawca/Dostawca jeszcze nie umożliwił dokonania walidacji produktu lub nie przekazał odpowiednich informacji na temat jego dostępności.

Spis treści książki

• Foreword
• Preface
  • Structure of This Book
  • AI-Aided Transformation
  • Conventions Used in This Book
  • OReilly Online Learning
  • How to Contact Us
  • Acknowledgments
• 1. Introduction: Domain-Driven Transformation in a Nutshell
  • Example: A Legacy System in a Container Port
    • Domain Rediscovery
    • Determining Target Architecture
    • Comparing Actual Architecture with Target Architecture
    • Prioritization and Implementation of the Transformation
    • What Has Just Happened?
  • The Method
    • Paths Through Domain-Driven Transformation
      • MMI 04: Big ball of mud
      • MMI 48: Technical layered architecture
        • Path A: Tactical transformation first
        • Path B: Strategical transformation first
        • Path A or path B?
      • MMI 810: Domain-driven modularization
  • Summary
• I. Fundamentals
• 2. Mastering Complexity
  • Origin of Complexity: Problem and Solution Space
  • Type of Complexity: Essential Versus Accidental
    • Sources of Accidental Complexity
    • Decision Areas of Software Architecture
    • Dealing with Essential and Accidental Complexity
  • Complexity in Legacy Systems
  • The Fundamental Methods
  • Whats Next?
• 3. Domain-Driven Design
  • DDD Concepts Against Complexity
  • DDD and the Business Domain
    • Ubiquitous Language
      • Collecting domain terms
      • Glossaries
      • Pollution of domain language with technological terms
      • English or the local language?
    • Strategic Design on the Business Side
    • Categorizing SubdomainsWhat Is Core?
      • Core domain
      • Generic and supporting subdomain
      • Core domain charts
  • DDD and the Software Solution
    • Strategic Design in the Software
      • Bounded context
      • Context map
    • Context Mapping
    • Bubble Context
    • The Domain Model
      • Domain model and bounded contexts
      • Reuse, duplication, and redundancy
    • The Layered Architecture in DDD
    • Tactical Design
    • Domain Events
  • Summary
• 4. Collaborative Modeling
  • Modeling Tools and the Model Monopoly
  • Collaborative Modeling Methods for Transformation
  • Bringing the Right People Together
  • Fundamental Concepts of Collaborative Modeling
  • Collaborative Modeling and DDD
  • Domain Storytelling
    • One PictureOne Story
    • Drawing Boundaries
    • Scope Factors for Domain Stories
    • Finding the Domain Model
    • Outlook
  • EventStorming
    • Exploring with Big Picture EventStorming
    • Chaotic Exploration
    • Enforcing the Timeline
    • People and Systems
    • Explicit Walkthrough
    • Value-Added Steps
    • Drawing Boundaries
    • The Color Coding
    • Deeper into the Details: Software Design EventStorming
    • Finding the Domain Model
    • Other Formats and Outlook
  • Scenario Casting
    • How Does the Method Work?
    • The Core Idea
    • Workshop Flow: From Exploration to Implementation
    • Introducing a Case Study: Green Urban Supplier
    • Step 1: Brainstorming
    • Step 2: Focusing
    • Step 3: Assembling
    • Whats Next in the Scenario-Based Approach?
    • The Second Round of Scenario Casting
    • Outlook
  • Which Method to Use When?
  • Collaborative Modeling Remote
  • Collaboration Modeling and AI
  • Other Collaborative Modeling Methods
  • Summary
• 5. Concepts of Software Architecture
  • Architecture Documentation with the C4 Model
    • Level 1: Context
    • Level 2: Containers
    • Level 3: Components
    • Level 4: Code
  • Modularity
  • Cohesion and Coupling
    • Cohesion and Coupling in DDD
    • Cohesion and Coupling in the Domain
  • Big Ball of Mud
    • At the Class Level
    • At the Architecture Level
    • Where Does the Big Ball of Mud Come From?
    • Coupling and Reuse
  • Architectural Styles for Legacy Systems
  • Monolith
  • Microservices
  • From Monolith to Microservices
  • The Good Old Layered Architecture
  • Inside-Outside Architectures: Hexagonal/Ports & Adapters, Onion, Clean, and More
    • Dierent Styles TogetherExplicit Architecture
    • Inside-Outside Architectures and Tactical DDD
  • Software Architecture Hamburger
  • Service-Oriented Architectures
  • Self-Contained Systems
  • From IT Landscapes to SOA and Back Again
  • The Modularity Maturity Index: Where Do You Stand?
    • Modularity in the MMI
    • Hierarchy in the MMI
    • Pattern Consistency in the MMI
  • Calculation of the MMI
  • Summary
• 6. How to Approach the Transformation
  • ReplacementBig Bang
  • ReplacementStep-by-Step
  • Reshaping
  • Summary
• II. Technical, Tactical, and Team-Organizational Domain-Driven Transformation
• 7. Technical Stabilization of Legacy Software
  • Updating the Integrated Development Environment
  • Automating Build and Deployment
  • Updating Software Dependencies
    • Updating Libraries and Frameworks
    • Updating the Programming Language
    • Resolving Compiler and IDE Warnings
  • Increase Test Coverage When Fixing Bugs
    • The Scout Rule (Formerly Known as the Boy Scout Rule)
    • Dierent Kinds of Tests
  • Cleaning Up the Code as You Go
  • Refactoring
    • Breaking Dependencies
    • Improving Internal Structure Using Metrics
  • Improving Error Robustness
    • Build Robustness Against Null
    • Improve the Use of Exceptions
    • Introduce Design by Contract
  • Summary
  • Where Do You Stand?Made Easy
• 8. Strengthening the Source Code with Domain Knowledge
  • Separating Business Source Code and Technical Source Code
  • Increasing Cohesion
    • Enrich Modeling with Domain Knowledge
    • Utilize Value Objects
    • Introduce Design by Contract
    • Make the Identity of Entities Explicit
  • Reduce Coupling
    • Break Cycles and Dependencies
    • Introduce ID References at Aggregate Boundaries
    • Reduce Inheritance in Business Source Code
    • The Liskov Substitution Principle
  • Documenting Architecture in Code
  • Does the AI have Knowledge About My Domain?
  • Summary
  • Where Do You Stand?Made Easy
• 9. Improving Team Organization
  • Software as a Sociotechnical System
    • Horizontal Architecture/Team Organization
      • Special case framework team
      • Problems with the horizontal decomposition
    • Vertical Architecture/Team Organization
    • How to Perform This Team Reorganization?
  • Team Topologies
    • Working in the Flow
    • Types of Topologies
    • Team Interaction Modes
    • Team Evolution Over Time
    • Architecture Modernization Enabling Teams
  • Summary
  • Where Do You Stand?Made Easy
• III. Strategic Domain-Driven Transformation
• 10. Step 1Domain Rediscovery
  • Schematic Description of Step 1
  • Challenge: Gathering the Right Domain Experts
  • Challenge: Leading Domain Experts Back to the Actual Domain
  • Substep 1.1: Getting to Know the As-Is Situation
  • Substep 1.2: Extracting the Domain Knowledge (Purication)
    • Technique: Thought Experiment Paper Process
    • Technique: Thought Experiment Virtual Actors
    • Alternative: Modeling Pure in the First Place
    • Distilling Ubiquitous Language
  • Substep 1.3: Optimizing the Business Processes
  • Substep 1.4: Finding Subdomains in the Business Processes
    • Indicators for Subdomain Boundaries
  • Challenge: Do Not Decompose by Work Items
  • Challenge: Finding the Right Size
    • Goals of the Right Size
    • Indicators for the Right Size
  • Discussing Decomposition with AI
  • Summary
• 11. Step 2Modeling the Domain-Driven Target Architecture
  • Schematic Description of Step 2
  • Substep 2.1: Creating a Context Map
  • Challenge: Solution-Space Induced Contexts
  • Substep 2.2: Categorizing Subdomains
  • Substep 2.3: Assigning Bounded Contexts to Teams
  • Challenge: Assigning Teams Often Means Shaping Teams
  • Substep 2.4: Determining Relationships
  • Putting It All Together
  • Summary
• 12. Step 3Alignment of Actual with Target Architecture
  • Schematic Description of Step 3
  • Substep 3.1: Identifying the Actual Architecture
    • Actual Architecture and AI
  • Substep 3.2: Comparing the Target Context Map and the Source Code
  • Challenge: Unbounded Models
    • Decomposition from Inside to Outside
  • Challenge: The Unbounded Domain Model
    • Problem Cause: Reusability Misunderstood
  • Challenge: The Unbounded Anemic Domain Model
  • Challenge: The Unbounded Data Model
  • Challenge: Decomposing the User Interface
    • Monolithic UI
    • UI in Context: Microfrontends
  • Substep 3.3: Compiling Refactorings and Findings
  • Summary
• 13. Step 4Prioritization and Implementation of the Transformation Measures
  • Schematic Description of Step 4
  • Substep 4.1: Selecting the First Strategic Refactoring
    • Pattern: Start with a Supporting Subdomain
    • Pattern: Proceed with a Core Domain
  • Substep 4.2: Adding Tactical Refactorings to the Product Backlog (or Improvement Backlog)
  • Substep 4.3: Planning Achievable Refactorings into the Sprint Backlog
    • Let the Refactoring Pause Only in Emergencies
    • Estimating Refactorings
    • Domain-Driven Transformation with Kanban
  • Substep 4.4: Extracting Context
  • Challenge: Disentangling Business Logic in Services
  • Challenge: Moving Local Data, Setters, and Getters into a Context
    • Identity of Entities
  • Challenge: Duplicating Data, Setters, and Getters into Multiple Contexts
  • Challenge: Introducing Domain Events Between Services
  • Challenge: Move Domain Logic Out of Services and into the Anemic Domain Model
    • Push Down Logic from Services into Anemic Entities
  • Challenge: Disentangling the Data Model
  • Challenge: Selecting Findings at the Appropriate Moment
  • Challenge: Keeping the Stamina
  • Summary
• IV. Conclusion
• 14. Outlook: Domain Patterns and Their Implementation in Bounded Contexts
  • Dimension 1: Workow in the Domain
    • Domain Pattern Pipeline
    • Domain Pattern Blackboard
    • Domain Pattern Dialog
    • Evolution of Domains and the Patterns They Follow
  • Dimension 2: The Domain Model in the Software
    • Central Domain Item Versus Diverse Domain Items
    • Form-Based Domain Model
  • Dimension 3: Shape of the Domain
    • Age and Maturity of the Domain
    • Tangible Objects Domain Versus Fully Digitalized Domain
    • Room for Transformation
  • Summary
• 15. Summarizing Domain-Driven Transformation
• A. Overview of the Catalog of Domain-Driven Refactorings
• B. Strategic Refactorings
  • Extract Bounded Context
    • Motivation
    • Mechanics
  • Implement Bounded Context from Scratch
    • Motivation
    • Mechanics
• C. Tactical Refactorings That Support Strategic Refactorings
  • Extract Specialized Service
    • Motivation
    • Mechanics
  • Extract Specialized Entity
    • Motivation
    • Mechanics
  • Extract Specialized Anemic Entity
    • Motivation
    • Mechanics
  • Extract Specialized Table
    • Motivation
    • Schema Update Mechanics
    • Data-Migration Mechanics
    • Access Program Mechanics
• D. Sociotechnical Refactorings
  • Form Cross-Functional Team Out of Layer-Team Members
    • Motivation
    • Mechanics
  • Form Second Cross-Functional Team Out of Partly Layer-Team and First-Team Members
    • Motivation
    • Mechanics
  • Form Second Team Out of Only Layer-Team Members
    • Motivation
    • Mechanics
• E. Tactical Refactorings That Strengthen Domain Knowledge
  • Enforce Ubiquitous Language
    • Motivation
    • Mechanics
  • Replace Primitive with Value Object
    • Motivation
    • Mechanics
  • Heal Entity Anemia
    • Motivation
    • Mechanics
  • Replace Setter
    • Motivation
    • Mechanics
  • Remove Setter
    • Motivation
    • Mechanics
  • Move Logic from Service to Entity
    • Motivation
    • Mechanics
  • Introduce Contract
    • Motivation
    • Mechanics
  • Split Active Record into Aggregate and Repository
    • Motivation
    • Mechanics
  • Split Repository into Interface and Implementation
    • Motivation
    • Mechanics
  • Extract Entity from Smart UI
    • Motivation
    • Mechanics
  • Extract Service from Smart UI
    • Motivation
    • Mechanics
• Bibliography
• Index

pokaż cały spis treści

ukryj recenzje