Process Type
Graphical expression
Mind Type
Structured expression
Note Type
Efficient expression
Treemap
Bracket Diagram
Default Mode
In software development , there is a perennial challenge: as business logic becomes increasingly complex, the code becomes increasingly difficult to maintain. Early CRUD applications based on the MVC architecture function well, but as business needs deepen, development teams quickly find themselves in a dilemma—"Where should the business logic be placed?"
Domain-Driven Design (DDD) was created to solve this problem. Proposed by software guru Eric Evans in 2003, it aims to build software models highly aligned with business needs by using business domain knowledge as the core driving force for system design. DDD is not a specific architectural style, but a complete and systematic design methodology that simplifies complex business domains through boundary delineation, helping us design clear domain and application boundaries.
This article will systematically explain the core concepts, strategic and tactical design, and layered architecture of DDD . Whether you are a developer who is new to DDD or a product manager or architect who wants to improve your architecture design capabilities, you can gain inspiration from it.
In traditional development models, business logic is often intertwined with database operations and framework features, resulting in poor code readability and high maintenance costs. The core idea of DDD is to completely separate pure business logic from technical implementation, allowing developers to think like business experts.
The primary principle of DDD is to establish a ubiquitous language. Everyone—including developers, testers, product managers, and business experts—should use a unified, domain-model-based common language. This means that class names and method names in the code must directly reflect business concepts, rather than vague terms like DataProcessor or Manager. For example, an e-commerce system should have an Order class and its place() method, instead of a generic OrderService that crams all the logic into it.
The second core concept of DDD is focusing on the core domain. In a complex business system, different subdomains have different business values. The core domain is a key factor for business success and requires the most design effort; the common domain is the common functionality shared by multiple subdomains; and the supporting domain is the infrastructure that supports other subdomains.
DDD practice has two dimensions: strategic design and tactical design. Strategic design focuses on domain division and boundary definition, solving the "what to do" problem; tactical design focuses on specific code implementation, solving the "how to do it" problem.
When faced with a large system, it is impractical to try to cover all business areas with a single model. The strategic design portion of DDD provides powerful tools for partitioning complex systems.
A domain refers to the problem area that an enterprise needs to solve. Taking a content community system as an example, the entire " content community " is a domain, which can be broken down into multiple subdomains such as user management , readers , payment , and community . Among them, the community may belong to the core domain, while payment belongs to the supporting domain.
Key takeaway: In strategic design, it is important to identify which subdomains are the core competencies of the business and concentrate resources on them.
DDD - Content Community Subdomain Diagram
This is the most important strategic pattern in DDD (Data Demand and Decision Making). It clearly defines the scope of a model's application, that is, "within which boundaries does this word mean?" For example, in the context of e-commerce goods, "product" has attributes such as price, description, and category; while in the context of logistics, "product" focuses more on weight and volume.
Each bounded context is an independent "semantic boundary," possessing a unified common language and domain model. The system is thus decomposed into multiple highly cohesive, loosely coupled modules.
Key principle: Bounded contexts clarify their relationship with other contexts through context mapping, thus avoiding model pollution.
[DDD Strategy Modeling] - Delineating Bounded Contexts
DDD (Data Dependency Analysis) and microservice architecture are a natural fit. A well-designed bounded context is naturally a candidate for a microservice. Conversely, blindly breaking down a system according to technical layers can easily lead to a distributed monolith—services may be separated, but coupling remains. In a microservice architecture, a service should be no smaller than an aggregate and no larger than a bounded context.
Within the bounded context, DDD provides a suite of tactical modeling tools for constructing domain models.
An entity is an object with a unique identifier and a lifecycle. For example, even if a user changes their name, their unique ID remains the same, and they are still the same entity. Entities typically employ a richness model, where business behaviors are encapsulated within the entity.
Value objects lack unique identifiers and are distinguished solely by their attribute values, and are typically immutable. For example, the amount (Money) is determined by the currency and the value; two Money values with the same amount and currency are interchangeable. Proper use of value objects can reduce system complexity; for instance, addresses, email addresses, and phone numbers can all be modeled as value objects.
An aggregation is a collection of related entities and value objects that are managed as a whole. The aggregation root is the core entity within the aggregation, responsible for maintaining consistency within the aggregation. For example, the Order aggregation root manages OrderItem and Payment entities; all access to order items must be done through Order.
Aggregate design principles: Transactions within an aggregate boundary should maintain consistency; references to other aggregates should be made only through identifiers, avoiding direct references across aggregates. Aggregates should be designed to be as small as possible.
This is a concept that beginners often find confusing. Domain services carry domain behaviors that cannot be attributed to entities or value objects. They belong to the domain layer, maintain domain purity, and do not involve technical details. For example, TransferService handles cross-account transfers; it does not belong to any single account entity, but it is core business logic.
Application services coordinate domain objects and domain services, handle application workflows, and belong to the application layer. Application services are stateless and are responsible for use case scheduling, transaction management, and security authentication, but do not contain business rules.
The repository acts as a bridge between the domain layer and the infrastructure layer. It is defined in the domain layer as an abstract interface, while the infrastructure layer implements the specific storage logic. The repository only exposes methods for accessing by aggregation, and does not expose ORM details.
Domain events are meaningful business events that occur within a domain, which can be used to trigger subsequent business logic and decouple modules.
Blog DDD Domain-Driven Tactical Design Diagram
DDD recommends a layered architecture, typically consisting of four layers: user interface layer, application layer, domain layer, and infrastructure layer.
This component is responsible for interacting with users, receiving requests, and returning responses. In a web application, it corresponds to the Controller, but is only responsible for parameter validation and result formatting, and does not contain business logic.
The domain objects are coordinated to complete business use cases, handling transaction boundaries, security, and authentication. Application layer services remain stateless, only calling domain services or aggregate root methods, and do not contain business rules.
The core of DDD includes all business rules and models. It defines aggregate roots, entities, value objects, and domain services to ensure the integrity of business logic.
It provides technical implementation support, such as database access, message queues, and external API calls. Through the dependency inversion principle, the domain layer defines interfaces, and the infrastructure layer implements them, achieving complete isolation between business logic and technical implementation.
In a DDD layered architecture, dependencies are directed from the outside in: the user interface layer depends on the application layer, the application layer depends on the domain layer, and the infrastructure layer's interface is defined by the domain layer through dependency inversion. The domain layer does not depend on any specific framework or technology, which allows core business logic to be replaced with alternative technologies without modification.
In practical implementation of DDD (Domain-Driven Design), visualization is a crucial step in helping teams build consensus. Whether it's bounded context delineation in the strategic design phase or domain model construction in the tactical design phase, clear diagrams are indispensable. ProcessOn, as a professional online diagramming tool, can efficiently support full-process visualization of DDD architectures.
1. Go to your ProcessOn profile page and create a "Flowchart", or search for keywords such as DDD architecture design in the template community.
2. On the left, under "More Graphics," you can select graphic categories such as flowcharts and UML diagrams to add to the graphic library. Drag and drop shapes such as rectangles and circles from the graphic library onto the canvas, and use arrowed lines to connect different elements to express dependencies.
3. When one or more elements are selected, the top toolbar can use different colors to distinguish different levels of the model, as well as to perform layout adjustments such as graphic alignment and layer settings.
4. Once the diagram is complete, you can click the share collaboration button in the upper right corner to share the DDD architecture diagram with colleagues or clients for continuous model iteration. You can also export it as a high-resolution image, PDF, SVG, or other formats for future reference.
Domain-driven design is not just a set of technical patterns or architectural specifications; it is a revolution in thinking and a systematic methodology for dealing with the core complexity of software. It teaches us that software development does not begin with creating tables, but with understanding the business.
By strategically defining domain boundaries and tactically designing a highly cohesive domain model, combined with a layered architecture to isolate business logic from technical implementation, DDD can significantly improve the maintainability and scalability of complex business systems. Especially in the microservices era, the bounded context partitioning method provided by DDD is the best practice for scientifically decomposing microservices.
Free online collaborative mind map flowchart
