Domain-Driven Design (DDD) Overview
Domain-Driven Design (DDD) is a software design methodology based on an understanding of business domains in software development.
DDD focuses on the business domain in software design and models the language, concepts, rules, and constraints for expressing business requirements and business processes. This is supposed to enable developers and domain experts to use a common language, facilitate communication, and realize software that meets business needs. DDD also recommends that software be partitioned based on the domain model, an approach that ensures that each layer of software follows the domain model and achieves a consistent design.
Although DDD is considered an effective method for developing enterprise applications and software with complex domain models, it is not necessarily suitable for all projects due to its learning and implementation costs. However, as described in “Overview of Microservices Architecture” DDD can be used as a complementary technique for microservices, a style of architecture in which applications are divided into small services and each service can be executed independently, although at different levels of abstraction. It is stated that they can be used as
This means that in a microservice architecture, the use of DDD allows each service to focus on its own domain and minimize the degree of coupling with other services, and that DDD allows the domain model to be more clearly defined so that each service can process accurate data and logic processing.
In addition, microservices architecture allows the domain model defined by DDD to be partitioned into services, making each service self-contained and much more flexible than a single large application, and furthermore, each service can be scaled independently This means that the performance and availability of the application is improved.
Software Development Flow in DDD
In DDD, the general flow of software development includes the following
- Understanding the Domain: acquire knowledge about the domain by understanding the purpose of the software and the business challenges. Dialogue with business experts and stakeholders is important in this process, and at this stage, terms and concepts about the domain are identified and a language is chosen to model these.
- Creating the model: Based on the domain knowledge, a domain model is created. The language used for modeling can be freely chosen according to business terminology, and at this stage, the model can be documented and checked for correctness.
- Establish a ubiquitous language: The language used for modeling is shared within the domain as a ubiquitous language. The ubiquitous language is used to link business terms with technical terms, allowing developers and domain experts to use a common language and facilitate communication.
- Architectural Design: Based on the model, the architecture of the system is designed. In this phase, the model is analyzed and divided into several subdomains to isolate different aspects of the domain. Domain objects such as repositories, factories, and services are also designed to ensure model consistency.
- Implementation and Testing: Based on the architectural design, the actual code is written. In this process, we implement the domain objects and use repositories, factories, services, etc. to realize the domain model. It also writes tests to ensure that the code works correctly.
- Continuous Improvement: As the system is actually used, new business requirements may emerge and the domain model may change. This necessitates continuous improvement of the system.
Examples of applications to which DDD applies
DDD is primarily applied to the development of large and complex software systems where the business logic is complex. The following are examples of applications where DDD may be applied
- Banking and insurance company systems
- Online store and marketplace systems
- Electronic medical record systems of medical institutions
- Transportation and logistics industry systems
- Airline and railroad company systems
- IoT devices and smart home systems
These applications often require complex domain knowledge, have complex business processes, and have multiple subdomains; DDD is designed to address these issues by building applications around domain models and ubiquitous languages, improve communication between developers and business experts, and increase software maintainability and scalability.
Relationship between DDD and AI applications
The relationship between DDD and AI applications can be considered relevant from several perspectives.
First, DDD is an architectural pattern for building applications around domain knowledge; even for AI applications, it is important to model domain knowledge appropriately; for example, when using AI technologies such as image recognition and speech recognition, it is For example, when using AI technologies such as image recognition and speech recognition, it is necessary to create models according to the domain knowledge. Thus, the DDD architectural pattern can be applied to AI applications as well.
In DDD, it is also important to share domain knowledge using a ubiquitous language, and similarly in AI applications, people from various backgrounds, such as business experts, AI engineers, and data scientists, should communicate using a common language This is necessary.
Furthermore, AI applications require decisions based on domain knowledge, such as model design and data preprocessing; DDD’s architecture can support such decisions by appropriately modeling domain knowledge.
reference book
Domain-Driven Design: Tackling Complexity in the Heart of Software” and “Implementing domain driven design” are well-known reference books on DDD.
Domain-Driven Design: Tackling Complexity in the Heart of Software” describes domain model design methods in detail.
The contents are as follows
Part 1 Making Domain Models Work
The Usefulness of Models in Domain-Driven Design
The Core of Software
Chapter 1: Chewing Up Knowledge.
Elements of Effective Modeling
Biting into Knowledge
Continuous Learning
Knowledge-Rich Design
Example 1.1--Eliciting Hidden Concepts
Deep modeling
Chapter 2: Communication and Language Usage
UBIQUITOUS LANGUAGE
Example 2.1--Completing a freight program
Modeling aloud
One language per team
Documentation and diagrams
Written design documentation
Executable foundation
Model for Explanation
Example 2.2--Transportation Operations and Routes
Chapter 3: Linking Model and Implementation
MODEL-DRIVEN DESIGN
Supported by Modeling Paradigms and Tools
Example 3.1--From Procedural to Model-Driven
Show the Skeleton: Why Models Matter to Users
Practical Modelers (HANDS ON MODELERS)
Part 2 Components of Model-Driven Design
Chapter 4: Isolating the Domain
LAYERED ARCHITECTURE (LAYERED ARCHITECTURE)
Example 4.1--separate online banking functionality into layers
Relating the Layers
Architectural Framework
The domain layer is where the model lives
Smart UI "anti-pattern" (SMART UI Meanti-Pattern Mo)
Other Isolation
Chapter 5: Models Represented in Software
Related
Example 5.1--Relationships in a brokerage account
ENTITIES (aka REFERENCE OBJECTS)
Modeling Entities
Design operations for identity
VALUE OBJECTS
Design value objects
Example 5.2--Tuning a database using value objects
Designing associations involving value objects
SERVICES
Domain layer isolated from services
Granularity
Access to services
MODULES (aka PACKAGES)
Agile modules
Example 5.3--Coding Conventions for Packages in Java
Pitfalls of infrastructure-driven packaging
The Modeling Paradigm
Why is the object paradigm so dominant?
What is not an object in an object world
Staying true to model-driven design when mixing paradigms
Chapter 6: The Domain Object Lifecycle
Aggregation (AGGREGATES)
Example 6.1--Purchase Order Consistency
FACTORIES
Select a factory and its location
When a constructor is all you need
Design the interface
Where should we put the logic for invariant conditions?
Entity Factories vs. Value Object Factories
Reconstructing stored objects
Repositories (REPOSITORIES)
Query against repositories
Client code ignores repository implementation, but developers do not
Implement the repository
Work within the scope of the framework
Relationships with Factories
Design objects to fit the relational database
Chapter 7: Using the Language: Applications
Implementing a Freight Transportation System
Isolating domains: Introducing applications
Distinguishing between Entity and Value Objects
Roles and other attributes
Designing transport domain associations
Aggregation Boundaries
Selecting a Repository
Walk through scenarios
Sample Application Feature: Changing the Outbound Destination of a Cargo
Sample Application Feature: Dealing with Repeaters
Object Creation
Factories and Constructors for Cargo
Adding cargo handling events
Stopping for Refactoring: Another Design on Freight Aggregation
Modules in the transport model
Introducing a new feature: allocation checks
Connecting two systems
Enhancing the model: business segmentation
Performance tuning
Finally
Part 3: Refactoring Towards Deeper Insight
Levels of Refactoring
Deep Model
Deep Model / Flexible Design
Discovery Process
Chapter 8 Breakthroughs
Breakthroughs
Not a bad model...
Breakthrough
A deeper model
Calm Decision Making
Conclusion
Opportunity
Focus on the Basics
Epilogue: Chain of New Insights
Chapter 9: Making Implicit Concepts Explicit
Digging out concepts
Listen to the words
Example 9.1--Listening for missing concepts in a transportation model
Scrutinize the awkwardness
Example 9.2--Getting Interest The Hard Way
Ponder the discrepancies
Read the literature
Example 9.3--Getting Interest Using the Literature
Try again and again
How to model less obvious concepts
Explicit constraints
Example 9.4--Rethinking: overbooking policies
Processes as domain objects
Specification (SPECIFICATION)
Application and implementation of specifications
Example 9.5--Storage in a Chemical Warehouse
Example 9.6--A working prototype of a warehouse storage service
Chapter 10: Flexible Design
INTENTION-REVEALING INTERFACES
Example 10.1--Refactoring: Paint Mixing Application
SIDE-EFFECT-FREE-FUNCTIONS
Example 10.2--Refactoring: Paint Mixing Application Revisited
ASSERTIONS
Example 10.3--Refactoring: Return to Paint Mixing
CONCEPTUAL CONTOURSES
Example 10.4--Occurrence Contours
STANDALONE CLASSES
CLOSURE OF OPERATIONS (CLOSURE OF OPERATIONS)
Example 10.5--Selecting from a Collection
Declarative Design
Domain Specific Language
Declarative Style of Design
Extending a specification with a declarative style
Example 10.6--Other ways to implement composite specifications
Angle of Attack
Carve out subdomains
Leverage established formalisms when possible
Example 10.7--Integrating patterns: share counting
Chapter 11: Applying the Analysis Pattern
Example 11.1--Getting Interest When using accounts
Example 11.1 (continued)--Insight on nightly batches
Analysis Patterns are knowledge that should be leveraged
Chapter 12: Relating Design Patterns to Models
STRATEGY (aka POLICY)
Example 12.1--Route Search Policy
COMPOSITE
Example 12.2--Transportation Routes Composed of Routes
Why Not Flyweight?
Chapter 13 Refactoring Toward Deeper Insight
Getting Started
Exploration Team
Predecessor's techniques
Designing for Developers
Timing
Opportunistic crises
Part 4: Strategic Design
Chapter 14: Maintaining Model Integrity
BOUNDED CONTEXT
Example 14.1--Reserved Contexts
Recognizing Divisions within a BOUNDED CONTEXT
CONTINUOUS INTEGRATION
CONTEXT MAP
Example 14.2--Two contexts in a transportation application
Tests performed at the boundaries of a context
Compose and document a context map
Relationships between bounded contexts
Shared kernel (SHARED KARNEL)
CUSTOMER/SUPPLIER DEVELOPMENT TEAMS (CUSTOMER/SUPPLIER DEVELOPMENT TEAMS)
Example 14.3--Revenue Analysis and Booking
CONFORMIST
ANTICORRUPTION LAYER
Designing the Anti-Corruption Layer Interface
Implementing the Anti-Corruption Layer
Example 14.4--Legacy Reservation Application
cautionary tale
SEPARATE WAYS
Example 14.5--Separation of Insurance Projects
OPEN HOST SERVICE (OPEN HOST SERVICE)
PUBLISHED LANGUAGE
Example 14.6--PUBLISHED LANGUAGE FOR CHEMISTRY
Unify the elephant model
Choose a model context strategy
Decision making in teams and at higher levels
Put yourself in the context
Transform the boundaries
Accept the unchangeable: outline the external system
Relationships with external systems
System under design
Meet special requirements in a different model
Deployment
Trade-offs
Project already in progress
Conversion
Merge context: separate paths → shared kernel
Merge contexts: shared kernel → continuous integration
Phasing out legacy systems
Public host services → Published languages
Chapter 15 Distillation
CORE DOMAIN
Selecting the Core
Who will do this work?
Expanding distillation
Generic Subdomains (GENERIC SUBDOMAINS)
Example 15.1--a tale of two time zones
Generic does not mean reusable
Project Risk Management
DOMAIN VISION STATEMENT
HIGHLIGHTED CORE
Distilled Documentation
Flagging the core
distillation document as a process tool
COHESIVE MECHANISMS (COHESIVE MECHANISMS)
Example 15.2--Mechanisms in the Organization Chart
Generic Subdomain vs. Cohesive Mechanisms
When a mechanism is part of a core domain
Example 15.3--One cycle: the organization chart absorbs the mechanisms again
distill it into a declarative style
SEGREGATED CORE
Cost of creating an isolated core
Evolve team decision making
Example 15.4--Isolating the core of a freight transport model
ABSTRACT CORE
Deep model distillation
Selecting Refactoring Targets
Chapter 16: Large-Scale Structure
EVOLVING ORDER (EVOLVING ORDER)
SYSTEM METAPHOR
The "naive metaphor" and why we don't need it
RESPONSIBILITY LAYERS
Example 16.1 -- Digging Deeper: Layering the Transportation System
Selecting the Right Layer
KNOWLEDGE LEVEL
Example 16.2--Employee Salaries and Pensions (1)
Example 16.3--Employee Salaries and Pensions (2) KNOWLEDGE LEVEL
PLUGGABLE COMPONENT FRAMEWORK
Example 16.4--SEMATECH CIM FRAMEWORK
How strict should the constraints by structure be?
Refactoring to a suitable structure
Minimalism
Communication and self-discipline
Reconfiguration leads to flexible design
Distillation reduces load
Chapter 17: Putting the Strategy Together
Combining large-scale structure with bounded context
Combining Large-Scale Structure and Distillation
Evaluate first
Who develops the strategy?
Structure emerging from application development
Customer-focused architecture teams
Six things essential to making strategic design decisions
Same applies to technical frameworks
Pay attention to the master plan
Conclusion
Epilogue
Outlook
Appendix Glossary References Index
Implementing domain-driven design is a refining of the practical methodology from the community and real-world business context of Domain-Driven Design: Tackling Complexity in the Heart of Software, which was published in 2003 and has changed over the past 10 years (2015). The book is a refinement of the practical methodology from the community and actual business situations, based on the changes in the computing environment that have occurred in the 10 years since the book was published in 2003 (published in 2015).
The following is a summary of the contents of the book.
Chapter 1: Invitation to DDD
Chapter 2 Domains, Subdomains, and Bounded Contexts
Chapter 3 Context Maps
Chapter 4 Architecture
Chapter 5 Entities
Chapter 6 Value Objects
Chapter 7 Services
Chapter 8 Domain Events
Chapter 9 Modules
Chapter 10 Aggregation
Chapter 11 Factories
Chapter 12 Repository
Chapter 13 Bounded Context Binding
Chapter 14 Applications
コメント