DDD
Domain-driven design is about software development 方法论. It proposes a development model based on domain development. Based on DDD theory, we can design high-quality software models.
It builds a domain model around business concepts to control the complexity of the business and solve the problem that software is difficult to understand and evolve.
Microservices
Microservice is a kind 架构风格of decentralized service governance through inter-process communication, fault tolerance and fault isolation.
DDD and Microservices
They are all high cohesion, low coupling, separating complexity from a business perspective and improving responsiveness.
High Cohesion: Bring related businesses together
Low coupling: split less related services into independent services
Using DDD to build microservices we will gain the following advantages :
-
Clear and standard design
-
Based on the domain model, it is conducive to the transfer and inheritance of domain knowledge
-
Help the team establish good communication
-
Assist in the evolution of the system architecture
-
Improve the team's design capabilities (object-oriented, architecture)
design
Domain design involves technology and business. How to make them work together?
Strategic Design (Business)
Domains, Subdomains, Bounded Contexts
-
Split the domain into subdomains and divide the core subdomain, support subdomain and general subdomain
-
Expand event storms with subdomains, divide bounded contexts according to context semantics, establish a common language, and complete domain modeling
-
Domain modeling will serve as an important basis for competence center planning
-
After completing the capability center map and priorities, complete the tactical design as an input to the microservice design
Tactical Design (Technology)
Aggregates, Aggregate Roots, Entities, Value Objects, Domain Services, etc.
-
Complete the design and implementation of microservices according to the domain model
-
Establish dependencies between aggregations, aggregation roots, entities, value objects, domain services and other objects, map them to services in the form of code objects, and use a layered architecture to complete the design and implementation of microservices
Layered architecture can adopt Clean Architecture
DDD practice process
We will complete the complete implementation of business and technology through DDD + Clean Architecture
Unified Language (Strategic Design)
Unite:
-
Domain Model Terminology
-
DDD schema name
Technology:
-
technical design terminology
-
technical terms
-
technical design patterns
business:
-
Domain Model Terminology
-
DDD schema name
-
business term
-
Design irrelevant business terms
Event Storm (Strategic Design)
Event Storming is a domain modeling practice that allows domain stakeholders to quickly understand business models
The complete process includes unifying language, proposing domain events, rules, commands, reading models, roles, dividing subdomains, voting, supplementing business opportunities and values, etc.
Next, let's simplify the steps
event preparation
People: business people, domain experts, technical people, architects, testers, etc.
Kanban: A whiteboard or drawing tool that can visualize the flow of events
Colorful stickers: fill in events, orders and more
Business scene
Specify the business scenario. Let me take an e-commerce project as an example.
Event Storm Results
Command storm results
look for aggregates
Aggregation: a collection of related domain models, try to ensure the invariance of encapsulated business, and ensure the cohesion of closely related domain models
-
Analyze the three questions in sequence of events
-
What is the domain model of event change
-
Whether the domain model can be accessed independently, yes it is aggregation
-
Can not be accessed independently, which domain model (aggregation) needs to be accessed, and put it in the corresponding aggregation
-
-
Commands posted to the left of the aggregate represent input, and events posted to the right of the aggregate represent output
-
Check whether the aggregation rules are met, and readjust the aggregation if it does not match
Aggregate results
In the process of searching for aggregation, new input commands may be generated due to business connection, which are represented by dotted lines
Bounded Context
Bounded Context: The business boundary of a scenario or environment
-
Based on the aggregation and domain model, judge the business problem they want to solve, if it is the same problem, put it into a bounded context, otherwise split it
-
If an aggregate solves multiple problems at the same time, the aggregate needs to be split, and the split aggregates are divided into different bounded contexts
-
The size of the business problem to be solved (change reasons, internal logic, etc.) needs to be completed together with domain experts
Bounded context results
bounded context map
When there are many contexts, and different teams are responsible for different contexts, in order to ensure efficient work, the relationship between different contexts can be defined to create a global view of all model contexts. There is a direction between two contexts, upstream (U or Upstream), downstream (D or Downstream)
Bounded context mapping result
Subdomain
A business domain or subdomain is a business area. A business domain or subdomain may include multiple business capabilities, and one business capability corresponds to one service.
The core subdomain refers to the main contributors to business success and is the core competitiveness of an enterprise.
Generic subdomains are used by the entire business system.
Underpinning the subdomain is a necessary capability to do business, but not a success factor.
In addition to the subdomains marked in the above bounded context results, subdomains such as finance, marketing, and purchasing can also be extended
Domain Object Relation (Tactical Design)
Decompose an aggregate and extract the domain objects contained in the aggregate
-
Business Immutability of Domain Objects
-
Domain objects have a consistent lifecycle
Defining Entities and Value Objects (Tactical Design)
Entity: There is a unique identifier, and the basis for judging whether entities are equal is also a unique identifier
Value Object: Represents an immutable value of a property
Take order aggregation as an example:
-
Order aggregation contains order entity, order line entity
-
The order entity contains the shipping address value object
Architecture design
We simply view architecture design as three levels:
-
Business Architecture: Design business modules and their relationships according to business requirements
DDD's domain modeling has actually helped us to do business architecture and system architecture
-
System Architecture: Design the modules and their relationships of systems and subsystems
In DDD, the business architecture can be directly mapped to the system architecture
Business changes will evolve into system architecture changes, affecting technical architecture changes
-
Technical Architecture: Design techniques and framework details
The technical architecture (microservices) solves the decoupling between subsystems, decentralized service governance and data governance
Clean Architecture
We mentioned inputs and outputs when looking for aggregates. After the collection of Clean Architecture and DDD, it is very suitable as an architecture landing guide using DDD methodology.
In order to better read the model design (the query business comparison often accounts for more than 80%), it may be a good choice to match the CQRS.
The advantage of CQRS lies in the separation of duties, improving system performance, scalability, security, etc. It is also possible to switch from data-driven to event-driven.
To understand CQRS, see the second MASA Framework - EventBus Design
Examples can refer to the MASA EShop source code: https://github.com/masalabs/MASA.EShop
In addition to DDD, we also provide a variety of implementation methods such as EventBus, Dapr, CQRS, etc.
Evolution of old systems
strangler mode
The strategy of building new functions into new services in a new way at the periphery of the existing system. By making new functions into microservices instead of directly modifying the original system, the old system can be gradually replaced. With this strategy, over time, the new service "strangles" the old system. The strangler pattern is recommended for legacy systems that are large and difficult to modify the existing architecture.
Cons: May take a while to maintain two or more projects at the same time
Repair mode
The repairer mode is like repairing a house or a road, isolating the old part to be repaired and repairing it individually in a new way. While repairing, it is necessary to ensure that it can still function in conjunction with other parts. From this line of thinking, the repairer model is more of a reconstruction technique.
DDD practice process
Summarize
Although DDD requires a certain learning cost, after mastering it, you can design complex projects or reduce the process appropriately. In small projects, you can directly abstract domain models with domains and aggregations, and cooperate with your accustomed technical means (such as DB First or Code First) to increase control over system design.
The first part mainly explains how DDD is implemented in the team, and the second part is how to implement it from the perspective of development.
Apply what you have learned, there is no end to learning.
refer to:
AWS Domain Driven Design Best Practices
Domain Driven Design in Practice in Internet Business Development: https://tech.meituan.com/2017/12/22/ddd-in-practice.html
open source address
MASA.BuildingBlocks：https://github.com/masastack/MASA.BuildingBlocks
MASA.Contrib：https://github.com/masastack/MASA.Contrib
MASA.Utils：https://github.com/masastack/MASA.Utils
MASA.EShop ：https://github.com/masalabs/MASA.EShop
MASA.Blazor：https://github.com/BlazorComponent/MASA.Blazor
If you are interested in our MASA Framework, whether it is code contribution, use, issue, please contact us