Ddd Architecture Awesome

DDD Architecture Awesome

The entry point to the DDD Skills ecosystem. This skill provides everything needed to understand DDD, decide if it's right for your project, and chart your learning path — all in one place.

When to Use (and When NOT to)

Start simple. Evolve complexity only when needed. Most systems don't need full CQRS or Event Sourcing.

When to trigger this skill

ALWAYS use this skill when the user mentions:

• "What is DDD", "Explain DDD", "DDD 是什么", "介绍一下 DDD"
• "Domain-Driven Design", "领域驱动设计"
• "DDD basics", "DDD fundamentals", "DDD 基础", "DDD 入门"
• "Should I use DDD", "DDD 适用场景", "DDD 是否适合"
• "DDD vs CRUD", "DDD vs traditional", "DDD 对比"
• "DDD concepts", "DDD 概念"
• "Strategic design DDD", "Tactical design DDD", "DDD 战略设计", "DDD 战术设计"
• "When to apply DDD", "When DDD is appropriate"
• Questions about DDD architecture types and their differences
• New to DDD and seeking guidance on where to start

---

1. DDD Definition

Domain-Driven Design is a development methodology that brings complex business rules into domain models: first define business boundaries (Strategic Design), then encode rules into models (Tactical Design).

Key insight: DDD is not about technology — it's about aligning your code with how the business thinks.

---

2. DDD Applicability Decision Tree

Evaluate along these dimensions and provide a "Suitable / Cautious / Not Recommended" conclusion:

Decision Flowchart

Is business logic complex (rules, state machines, constraints)?
├── NO → Is system long-lived (> 2 years)?
│         ├── NO → ✗ DDD NOT RECOMMENDED (Use simple CRUD + Service)
│         └── YES → ~ Cautious: adopt tactical patterns selectively
│
└── YES → Is there a domain expert or stable product owner?
          ├── NO → ~ Cautious: DDD without domain expert = complex code for nothing
          └── YES → Is the team familiar with DDD or willing to learn?
                    ├── NO → ~ Cautious: start with Layered, evolve later
                    └── YES → Do you need to swap infrastructure (DB, MQ)?
                              ├── NO → ✓ DDD RECOMMENDED (COLA or Layered)
                              └── YES → ✓ DDD STRONGLY RECOMMENDED (Hexagonal/Clean)

---

3. Complexity Ladder — Don't Skip Levels

Each level adds real complexity. Move up only when you've proven the current level insufficient.

Level 1: Simple Layered (Controller → Service → Repository)
   ↓ When business rules grow complex and need explicit modeling
Level 2: DDD 4-Layer with Rich Domain Model (Layered)
   ↓ When need multiple entry points (REST + CLI + MQ + gRPC)
Level 3: Ports & Adapters (Hexagonal Architecture)
   ↓ When read/write patterns diverge significantly
Level 4: CQRS — Separate Read/Write Models
   ↓ When need complete audit trail / temporal queries
Level 5: Event Sourcing — Store events, derive state

Your project Level: ___ (Recommend with reasoning)

---

4. Pattern Boundaries — What Each Pattern IS and IS NOT

This table solves the most common DDD confusion: "What's the difference between these patterns, and when should I use each one?"

---

5. DDD Architecture Landscape Overview

DDD Architecture Family:

  Foundational (Learning cost: Low → Medium):
  ├── Layered Architecture (分层架构)
  │   └── Classic 4-layer: Interface → Application → Domain ← Infrastructure
  │       1-5 people | CRUD-friendly | Spring Boot native
  │
  ├── Onion Architecture (洋葱架构)
  │   └── Domain core, concentric dependency rings, inner defines interface
  │       5-15 people | High testability | Frequent infra changes
  │
  ├── Hexagonal Architecture (六边形架构 / Ports & Adapters)
  │   └── Domain at center, ports define contracts, adapters implement
  │       5-15 people | Multi-entry systems | Best testability
  │
  Advanced (Learning cost: Medium → High):
  ├── Clean Architecture (整洁架构)
  │   └── Entities → Use Cases → Interface Adapters → Frameworks
  │       15-50 people | Enterprise systems | Strict module isolation
  │
  └── COLA Architecture (COLA v5 架构)
      └── Diamond pattern: Adapter → App → Domain ← Infrastructure
          5-50 people | Chinese enterprise | Best tooling & community

  Complementary Patterns:
  ├── CQRS — Separate read/write models (L1: Model only / L2: DB separation / L3: Event Sourcing)
  ├── Domain Events — Cross-aggregate eventual consistency
  └── Event Sourcing — Store events as source of truth

Architecture Visual Comparison

Layered        Onion        Hexagonal      Clean          COLA v5
┌────────┐   ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐
│Interf. │   │ Infra    │  │ Adapter  │  │ Frame.   │  │ Adapter  │
├────────┤   │ ┌──────┐ │  ├──────────┤  ├──────────┤  ├──────────┤
│  App   │   │ │ App  │ │  │  Ports   │  │ Adapter  │  │   App    │
├────────┤   │ │┌────┐│ │  ├──────────┤  ├──────────┤  ├──────────┤
│ Domain │   │ ││Dom.││ │  │ Domain ★ │  │ Domain ★ │  │ Domain ★ │
├────────┤   │ ││ ★  ││ │  └──────────┘  └──────────┘  ├──────────┤
│ Infra  │   │ │└────┘│ │                              │ Infra    │
└────────┘   │ └──────┘ │                              └──────────┘
             └──────────┘

---

6. Core DDD Concepts Quick Reference

6.1 Strategic Design (战略设计)

6.2 Tactical Design (战术设计)

6.3 Quick Decision Trees

"Where does this code go?"

Where does this code go?
├─ Pure business logic, no I/O           → domain/
├─ Orchestrates domain + has side effects → application/
├─ Talks to external systems              → infrastructure/
├─ Defines HOW to interact (interface)    → port (domain or application)
└─ Implements a port                      → adapter (infrastructure)

"Entity or Value Object?"

Entity or Value Object?
├─ Has unique identity that persists → Entity
├─ Defined only by its attributes    → Value Object
├─ "Is this THE same thing?"         → Entity (identity comparison)
└─ "Does this have the same value?"  → Value Object (structural equality)

"Should this be its own Aggregate?"

Aggregate boundaries?
├─ Must be consistent together in a transaction → Same aggregate
├─ Can be eventually consistent                 → Separate aggregates
├─ Referenced by ID only                        → Separate aggregates
└─ >10 entities in aggregate                    → Split it

Rule: One aggregate per transaction. Cross-aggregate consistency via domain events (eventual consistency).

---

7. Rich Domain Model vs Anemic CRUD (Critical Distinction)

// ❌ Anemic Model (Anti-Pattern) — Data bag + Service
@Entity
public class Order {
    private Long id;
    private String status;       // String instead of Value Object
    // Only getters/setters, NO behavior
}

@Service
public class OrderService {       // God Service with all logic
    @Transactional
    public void pay(Long orderId) {
        Order order = orderRepo.findById(orderId);
        if ("DRAFT".equals(order.getStatus())) {  // Raw string comparison
            order.setStatus("PAID");
            orderRepo.save(order);
        }
    }
}

// ✅ Rich Domain Model (DDD) — Behavior WITH data
public class Order extends AggregateRoot<OrderId> {
    private OrderStatus status;      // Value Object
    private Money totalAmount;
    private List<OrderItem> items;

    public void pay() {              // Behavior in entity
        if (!status.canPay()) {
            throw new OrderException("Cannot pay in current status");
        }
        this.status = OrderStatus.PAID;
        addDomainEvent(new OrderPaidEvent(this.id));
    }
}

Aggregate Sizing Heuristics

---

8. Anti-Patterns (CRITICAL — with Fixes)

---

9. Implementation Order (Universal)

1. Discover the Domain — Event Storming, conversations with domain experts
2. Model the Domain — Entities, value objects, aggregates (NO infrastructure)
3. Define Ports — Repository interfaces, external service interfaces
4. Implement Use Cases — Application services coordinating domain
5. Add Adapters LAST — HTTP, database, messaging implementations

DDD is collaborative. Modeling sessions with domain experts are as important as code patterns.

---

10. How to Use This Skill

Step 1: Understand user context

Ask about: project nature, business complexity, team structure, current state.

Step 2: Assess DDD applicability

Run through the decision tree (Section 2) and output:

• Suitable: Proceed to architecture selection
• Cautious: Recommend selective adoption
• Not Recommended: Explain why, prevent over-engineering

Step 3: Recommend learning path

Step 4: Output format

Always structure response with: 1. 适用性评估 (Applicability Assessment) — clear conclusion + reasoning per dimension 2. DDD 核心概念速览 (Core Concepts Quick Reference) — tailored to context 3. 推荐学习路径 (Recommended Learning Path) — which skills, what order

---

11. Sources

Primary Sources — Original Papers & Books

• Domain-Driven Design: The Blue Book — Eric Evans (2003)
• Implementing Domain-Driven Design — Vaughn Vernon (2013)
• Hexagonal Architecture — Alistair Cockburn (2005)
• The Clean Architecture — Robert C. Martin (2012)
• Onion Architecture — Jeffrey Palermo (2008)

Primary Pattern References

• CQRS — Martin Fowler
• Event Sourcing — Martin Fowler
• Repository Pattern — Martin Fowler (PoEAA)
• Unit of Work — Martin Fowler (PoEAA)
• Bounded Context — Martin Fowler
• Effective Aggregate Design — Vaughn Vernon

Implementation Guides

• Microsoft: DDD + CQRS Microservices
• Domain Events – Salvation — Udi Dahan
• Transactional Outbox — microservices.io
• Introducing Event Storming — Alberto Brandolini
• C4 Model — Simon Brown
• Documenting Architecture Decisions — Michael Nygard

Supplemental Syntheses

• Clean Architecture: Standing on the Shoulders of Giants — Herberto Graça
• Explicit Architecture — Herberto Graça
• Get Your Hands Dirty on Clean Architecture — Tom Hombergs
• COLA 5.0 Architecture — Alibaba

Chinese Resources (中文资源)

• PartMe DDD 系列文章 — 基础篇/进阶篇/实战篇
• Spring AI 官方文档

Reference Implementations by Language

---

Reference Library（按需加载）

This skill bundles a structured reference library organized by learning path. Each file is loaded only on demand — when the agent identifies the need.

How to use these references

When a user asks a question, find the matching category below and read the relevant file(s). Do NOT load all references at once.

End-to-End Examples

Examples differ from references: references teach concepts and principles; examples demonstrate application in concrete business contexts with real code. Load these when the user wants to see DDD applied to a realistic scenario.

Principle: "Don't apply DDD everywhere. Apply it where it matters."

>

After this, use ddd-architecture-selector to choose the right architecture pattern, then dive into domain modeling with ddd-domain-designer and implementation with the specific architecture skill.

---

Gotchas — Common Pitfalls

• "DDD = COLA" 误解: DDD 不是等于 COLA 框架。COLA 只是阿里体系中一种落地方案。还有 Layered、Onion、Hexagonal、Clean 等多种架构可选。根据项目实际需求选择。
• 一上来就搞 CQRS + Event Sourcing: 绝大多数项目不需要 Event Sourcing。先评估是否真的需要完整审计追踪和时间旅行查询。从最简单的分层架构开始。
• 把 DDD 当银弹: DDD 适合复杂业务领域，对于简单 CRUD 项目反而是过度设计。判断标准：业务规则 > CRUD 操作，有领域专家参与，需要长期维护。
• 战术设计先于战略设计: 直接写 Entity/ValueObject 而不先做 Bounded Context 划分。没有战略边界的战术设计会导致上下文混乱和模型冲突。
• 领域专家参与不足: DDD 需要领域专家持续参与。开发人员凭自己对业务的理解建模，产出的模型很可能偏离真实业务。

When NOT to Use This Skill

Security & Stability

• All code examples and concept illustrations are for educational purposes. They contain no real credentials or sensitive data.
• This skill teaches DDD methodology and patterns. It does not execute code, access external systems, or modify any project files.
• DDD's bounded context isolation naturally promotes security boundaries between different parts of the system.
• No executable scripts bundled. This skill is a pure learning and reference resource.

🧭 DDD Skills Journey

📍 You are here: `ddd-architecture-awesome` — Step 1: DDD 入门与全景

flowchart LR
    S1["⭐ Step 1<br/>awesome<br/>入门与全景"] --> S2["Step 2<br/>selector<br/>架构选型"]
    S2 --> S3A["Step 3<br/>layered<br/>分层架构"]
    S2 --> S3B["Step 3<br/>onion<br/>洋葱架构"]
    S2 --> S3C["Step 3<br/>hexagonal<br/>六边形架构"]
    S2 --> S3D["Step 3<br/>clean<br/>整洁架构"]
    S2 --> S3E["Step 3<br/>cola<br/>COLA v5"]
    S3A & S3B & S3C & S3D & S3E --> S4A["Step 4<br/>domain-designer<br/>领域建模"]
    S3A & S3B & S3C & S3D & S3E --> S4B["Step 4<br/>cqrs-architecture<br/>CQRS"]
    S3A & S3B & S3C & S3D & S3E --> S4C["Step 4<br/>api-designer<br/>API设计"]
    S4A & S4B & S4C --> S5["Step 5<br/>code-reviewer<br/>代码审查"]
    S5 --> S6A["Step 6<br/>event-storming<br/>事件风暴"]
    S5 --> S6B["Step 6<br/>testing-strategist<br/>测试策略"]
    S5 --> S6C["Step 6<br/>devops-integration<br/>DevOps"]
    S5 --> S6D["Step 6<br/>evaluator<br/>架构评估"]
    S6A & S6B & S6C & S6D --> S7["🏁 Step 7<br/>architecture-doc<br/>架构文档"]

    style S1 fill:#10b981,stroke:#059669,color:white,stroke-width:3px

← Previous: 你已经在 DDD 旅程的起点 🚀 → Next: selector — 选择适合你项目的架构模式 🔗 Related: domain-designer — 直接开始领域建模 | event-storming — 先做事件风暴工作坊 🏠 Home: 你在起点

💡 你是第一次接触 DDD？读完 Section 4 的 Pattern Boundaries 表和 Section 6 的核心概念速查，然后去 selector 选架构。

📋 See DESIGN.md for the complete 16-skill ecosystem map.

考勤请假系统 — DDD 端到端全流程案例

来源：极客时间 DDD实战课 第18讲 | 展示从战略设计到战术设计的完整过程

项目背景

在线请假考勤系统：请假人提交审批 → 逐级核批 → 考勤统计。同时支持内外网，内外部人员无差异管理。

一、战略设计（事件风暴）

1.1 场景分析

1.2 领域对象提取

1.3 聚合设计

请假聚合：
├── 请假单 (聚合根)
│   ├── 属性：请假类型、起止时间、天数
│   ├── 方法：create(), submit(), approve(), reject()
│   └── 值对象：请假人、审批人、请假类型、审批状态、审批规则
├── 审批意见 (实体) — 多级审批产生多条
│   ├── 属性：审批人、审批状态、审批意见
│   └── 方法：agree(), reject()
└── 审批规则 (值对象)
    └── 根据请假类型和天数确定审批层级

人员组织关系聚合：
├── 人员 (聚合根)
│   ├── 属性：姓名、工号、岗位、部门
│   └── 方法：getSupervisor(orgType)
└── 组织关系 (实体)
    └── 属性：组织关系类型、上级领导

考勤聚合：(非典型聚合，无聚合根)
├── 刷卡明细 (实体)
├── 考勤明细 (实体) — 核销请假后生成
└── 考勤统计 (实体) — 汇总计算

1.4 限界上下文 & 微服务拆分

二、战术设计（请假微服务为例）

2.1 服务识别

提交审批流程：
├── 应用服务：LeaveApplicationService.submitForApproval(leaveId)
├── 领域服务：
│   ├── ApprovalRuleService.getApprovalRule(leaveType, duration) → 审批规则
│   │   └── ApprovalRule.queryRule(leaveType, duration)
│   └── PersonService.getApprover(roleType) → 审批人
│       └── Person.getSupervisor(orgType)
└── 实体方法：
    └── Leave.assignApprover(approver, rule) → 分配审批人并保存规则

2.2 领域事件

2.3 代码结构

leave-microservice/
├── interfaces/
│   ├── controller/LeaveController.java
│   ├── dto/LeaveDTO.java, ApprovalDTO.java
│   └── assembler/LeaveAssembler.java
├── application/
│   ├── service/LeaveAppService.java          # 编排
│   └── event/publish/LeaveEventPublisher.java
├── domain/
│   ├── leave/                                # 请假聚合
│   │   ├── entity/Leave.java (聚合根), Approval.java (实体)
│   │   ├── vo/LeaveType.java, ApprovalStatus.java, Approver.java
│   │   ├── service/ApprovalRuleService.java
│   │   ├── event/LeaveSubmittedEvent.java, LeaveApprovedEvent.java
│   │   └── repository/LeaveRepository.java (接口)
│   └── person/                               # 人员组织关系聚合
│       ├── entity/Person.java (聚合根), OrgRelation.java (实体)
│       ├── vo/OrgType.java
│       ├── service/PersonService.java
│       └── repository/PersonRepository.java (接口)
└── infrastructure/
    ├── persistence/
    │   ├── LeaveRepositoryImpl.java
    │   └── PersonRepositoryImpl.java
    └── config/

2.4 关键代码

// 聚合根 — 请假单
public class Leave extends AggregateRoot<LeaveId> {
    private LeaveId id;
    private Applicant applicant;
    private LeaveType type;
    private LocalDate startDate, endDate;
    private LeaveStatus status;
    private List<Approval> approvals = new ArrayList<>();
    private ApprovalRule rule;

    public void submit() {
        if (status != LeaveStatus.DRAFT) throw new LeaveException("Only DRAFT can submit");
        this.status = LeaveStatus.SUBMITTED;
        addDomainEvent(new LeaveSubmittedEvent(this.id, this.applicant, this.type));
    }

    public void assignApprover(Approver approver, ApprovalRule rule) {
        this.rule = rule;
        this.approvals.add(new Approval(approver, ApprovalStatus.PENDING));
    }

    public void approve(Approver approver, String comment) {
        Approval current = findPendingApproval(approver);
        current.approve(comment);
        Approval next = rule.getNextLevel(this.approvals.size());
        if (next == null) {
            this.status = LeaveStatus.APPROVED;
            addDomainEvent(new LeaveApprovedEvent(this.id));
        } else {
            this.approvals.add(next);
        }
    }
}

三、从本案例学到的关键点

1. 非典型聚合处理：考勤聚合无聚合根，仍用聚合封装，照常设计实体和仓储 2. 聚合间通过应用层编排：请假提交审批需要请假聚合 + 人员聚合协作，通过应用服务编排 3. 领域事件驱动跨微服务：审批通过后通过事件将请假数据发到考勤微服务 4. 聚合是微服务演进的最小单位：人员组织关系聚合可随时从请假微服务中独立出来

电商订单系统 — DDD 端到端示例

基于 DDD 的电商订单系统完整案例，覆盖从战略设计到代码落地的全过程。

业务背景

一个典型 B2C 电商平台的订单模块：

• 用户下单 → 库存扣减 → 支付 → 发货 → 签收
• 支持订单改价、取消、退款等逆向流程
• 与会员系统、商品系统、物流系统等外部上下文协作

战略设计（Strategic Design）

领域划分

限界上下文

┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│  Order BC    │───→│ Payment BC   │───→│  Gateway BC  │
│  (订单上下文)  │    │  (支付上下文)  │    │  (支付网关)   │
└──────┬───────┘    └──────────────┘    └──────────────┘
       │
       │ ACL (防腐层)
       ▼
┌──────────────┐    ┌──────────────┐
│ Product BC   │    │  Member BC   │
│  (商品上下文)  │    │  (会员上下文)  │
└──────────────┘    └──────────────┘

上下文映射

战术设计（Tactical Design）

聚合设计

Order 聚合（聚合根：Order）

Order (Aggregate Root)
├── OrderId (VO)
├── BuyerId (VO — Member BC 的 ID 引用)
├── OrderStatus (VO: DRAFT → PAID → SHIPPED → DELIVERED → CANCELLED)
├── Money totalAmount (VO)
├── Address shippingAddress (VO)
├── List<OrderItem> items (Entity)
│   ├── ProductId (VO)
│   ├── Money unitPrice (VO)
│   └── int quantity
├── ── 行为 ──
├── void place()           // 下单
├── void pay()              // 支付完成
├── void ship()             // 发货
├── void deliver()          // 签收
├── void cancel(String reason)  // 取消
└── ── 事件 ──
    ├── OrderPlacedEvent
    ├── OrderPaidEvent
    ├── OrderShippedEvent
    └── OrderCancelledEvent

聚合设计原则体现

值对象设计

// 不可变值对象
public record Money(BigDecimal amount, Currency currency) {
    public Money add(Money other) {
        if (!this.currency.equals(other.currency)) {
            throw new IllegalArgumentException("Currency mismatch");
        }
        return new Money(this.amount.add(other.amount), this.currency);
    }
}

public record OrderStatus(String code) {
    public static final OrderStatus DRAFT = new OrderStatus("DRAFT");
    public static final OrderStatus PAID = new OrderStatus("PAID");
    public static final OrderStatus SHIPPED = new OrderStatus("SHIPPED");
    public static final OrderStatus DELIVERED = new OrderStatus("DELIVERED");
    public static final OrderStatus CANCELLED = new OrderStatus("CANCELLED");

    public boolean canPay() { return this == DRAFT; }
    public boolean canShip() { return this == PAID; }
    public boolean canCancel() { return this == DRAFT || this == PAID; }
}

领域事件与流程

Order.placed → InventoryDeductionRequested → Inventory.deduct
Order.paid → PaymentConfirmed → Order.status=PAID
Order.paid → ShipmentRequested → Shipment.create
Shipment.picked → OrderShipped → Order.status=SHIPPED
Shipment.delivered → OrderDelivered → Order.status=DELIVERED

分层架构落地

ecommerce-order/
├── order-adapter/            # 适配器层
│   ├── web/                  # REST Controller
│   │   ├── OrderCommandController.java
│   │   └── OrderQueryController.java
│   └── event/                # 事件消费者
│       └── PaymentEventConsumer.java
├── order-app/                # 应用层
│   ├── command/
│   │   ├── PlaceOrderCommand.java
│   │   ├── PayOrderCommand.java
│   │   └── CancelOrderCommand.java
│   ├── query/
│   │   └── OrderQueryService.java
│   └── event/
│       └── OrderEventPublisher.java
├── order-domain/             # 领域层
│   ├── model/
│   │   ├── Order.java        # 聚合根
│   │   ├── OrderItem.java    # 实体
│   │   └── vo/               # 值对象
│   ├── service/
│   │   └── OrderDomainService.java
│   └── repository/
│       └── OrderRepository.java  # 接口
└── order-infrastructure/     # 基础设施层
    ├── repository/
    │   └── OrderRepositoryImpl.java
    └── mapper/
        └── OrderMapper.java

关键代码片段

聚合根示例

public class Order extends AggregateRoot<OrderId> {
    private OrderId id;
    private BuyerId buyerId;
    private OrderStatus status;
    private Money totalAmount;
    private Address shippingAddress;
    private List<OrderItem> items = new ArrayList<>();
    private LocalDateTime createdAt;

    public Order(OrderId id, BuyerId buyerId, Address shippingAddress) {
        this.id = id;
        this.buyerId = buyerId;
        this.status = OrderStatus.DRAFT;
        this.shippingAddress = shippingAddress;
        this.createdAt = LocalDateTime.now();
    }

    public void addItem(ProductId productId, Money unitPrice, int quantity) {
        if (this.status != OrderStatus.DRAFT) {
            throw new OrderException("Only draft orders can add items");
        }
        this.items.add(new OrderItem(productId, unitPrice, quantity));
    }

    public void place() {
        if (this.items.isEmpty()) {
            throw new OrderException("Order must have at least one item");
        }
        this.totalAmount = items.stream()
            .map(OrderItem::subtotal)
            .reduce(Money::add)
            .orElseThrow();
        addDomainEvent(new OrderPlacedEvent(this.id, this.totalAmount));
    }

    public void pay() {
        if (!this.status.canPay()) {
            throw new OrderException("Cannot pay order in status: " + this.status);
        }
        this.status = OrderStatus.PAID;
        addDomainEvent(new OrderPaidEvent(this.id));
    }

    public void cancel(String reason) {
        if (!this.status.canCancel()) {
            throw new OrderException("Cannot cancel order in status: " + this.status);
        }
        this.status = OrderStatus.CANCELLED;
        addDomainEvent(new OrderCancelledEvent(this.id, reason));
    }
}

从本案例学到的 DDD 关键点

1. 聚合设计：Order 聚合只包含紧密相关的 OrderItem，Product 和 Member 通过 ID 引用 2. 值对象：Money、OrderStatus、Address 都是不可变值对象，自带业务行为 3. 领域事件：状态变更通过领域事件传播，实现聚合间最终一致性 4. 充血模型：place()、pay()、cancel() 业务方法在聚合根上，不是 Service 5. 防腐层：外部上下文数据通过 ACL 转换，不污染本上下文模型

保险投保系统 — DDD 聚合设计深度案例

基于 DDD 的保险投保系统，重点展示复杂聚合的设计方法。

业务背景

保险投保核心流程：

• 用户创建投保单 → 选择险种 → 填写标的信息 → 填入被保人 → 核保 → 缴费 → 出单
• 涉及多个参与方：投保人、被保人、受益人
• 复杂的业务规则：年龄校验、健康告知、保额计算、费率表

领域划分

限界上下文

┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│ Proposal BC  │────→│ Underwrite BC│────→│  Reinsure BC │
│  (投保上下文)  │     │  (核保上下文)  │     │  (再保上下文)  │
└──────┬───────┘     └──────┬───────┘     └──────────────┘
       │                    │
       ↓                    ↓
┌──────────────┐     ┌──────────────┐
│ Product BC   │     │ Payment BC   │
│  (产品上下文)  │     │  (支付上下文)  │
└──────────────┘     └──────────────┘

聚合设计 — 重点

投保单聚合（Proposal Aggregate）

这是一个典型的复杂聚合，包含多个实体和值对象：

Proposal (聚合根)
├── ProposalId (VO)
├── ProposalStatus (VO: DRAFT → SUBMITTED → UNDERWRITING → APPROVED → PAID → ISSUED)
├── Applicant (VO: 投保人信息)
│   ├── Name, IDNumber, Phone, Address
├── List<Insured> (Entity: 被保人)
│   ├── InsuredId
│   ├── Name, IDNumber, Age, Gender
│   ├── HealthDeclaration (VO: 健康告知)
│   └── Occupation (VO)
├── List<Coverage> (Entity: 险种)
│   ├── ProductId (VO — 外部引用)
│   ├── Money sumInsured (VO: 保额)
│   └── Money premium (VO: 保费)
├── List<Beneficiary> (VO: 受益人 — 不可变，无独立生命周期)
├── ── 行为 ──
├── void addInsured(Insured)
├── void addCoverage(ProductId, Money sumInsured)
├── void calculatePremium(RateTable)   // 保费计算
├── void submit()                       // 提交核保
├── void approve()                      // 核保通过
├── void reject(String reason)          // 核保拒绝
└── ── 事件 ──
    ├── ProposalSubmittedEvent
    ├── UnderwritingApprovedEvent
    └── PolicyIssuedEvent

聚合设计决策分析

聚合大小分析

为什么 Coverage 放在 Proposal 而非独立聚合？

1. 一致性要求：保额和保费的修改必须和投保单状态保持强一致 2. 不变量：投保单提交时，所有 Coverage 的 premium 总和必须等于 totalPremium 3. 生命周期：Coverage 随投保单创建和销毁，无独立生命周期

领域服务

// PremiumCalculator — 保费计算（跨实体逻辑，不适合放在聚合根或实体中）
public class PremiumCalculator {
    public Money calculate(Insured insured, ProductId product, Money sumInsured, RateTable rateTable) {
        // 1. 根据被保人年龄查费率
        BigDecimal rate = rateTable.findRate(insured.getAge(), product);
        // 2. 根据职业类别调整系数
        BigDecimal occupationFactor = insured.getOccupation().getFactor();
        // 3. 计算保费 = 保额 × 费率 × 职业系数
        return sumInsured.multiply(rate).multiply(occupationFactor);
    }
}

分层架构代码示例

// Domain Layer — 聚合根
public class Proposal extends AggregateRoot<ProposalId> {
    private Applicant applicant;
    private List<Insured> insureds = new ArrayList<>();
    private List<Coverage> coverages = new ArrayList<>();
    private List<Beneficiary> beneficiaries = new ArrayList<>();
    private ProposalStatus status = ProposalStatus.DRAFT;

    public void addCoverage(ProductId productId, Money sumInsured, RateTable rateTable) {
        if (status != ProposalStatus.DRAFT) {
            throw new ProposalException("Only draft proposals can modify coverage");
        }
        Coverage coverage = new Coverage(productId, sumInsured);
        for (Insured insured : insureds) {
            Money premium = new PremiumCalculator()
                .calculate(insured, productId, sumInsured, rateTable);
            coverage.addPremium(insured.getId(), premium);
        }
        this.coverages.add(coverage);
    }

    public void submit() {
        if (insureds.isEmpty()) throw new ProposalException("At least one insured required");
        if (coverages.isEmpty()) throw new ProposalException("At least one coverage required");
        this.status = ProposalStatus.SUBMITTED;
        addDomainEvent(new ProposalSubmittedEvent(this.id));
    }
}

从本案例学到的 DDD 关键点

1. 聚合边界决策：不是越细越好，要根据一致性要求和不变量来判断 2. 实体 vs 值对象：关键在于是否有独立标识和生命周期 3. 领域服务：跨实体的计算逻辑（如保费计算）放入领域服务，保持实体纯粹 4. 聚合大小权衡：3 个实体是健康范围，超出 5 个实体需要警惕 5. ID 引用外部聚合：Product 只用 ProductId 引用，避免跨聚合直接依赖

Why DDD — 领域驱动设计的价值与适用场景

DDD 核心定义

DDD 是一种处理高度复杂领域的设计方法论，通过边界划分将复杂业务领域简单化，建立清晰的领域和应用边界。

DDD 不是架构，而是架构设计方法论。它由两部分组成：

DDD 与微服务的关系

核心公式: 战略设计划定边界 → 限界上下文映射为微服务 → 战术设计实现代码

DDD 适用性评估

三步决策法

1. 业务逻辑是否复杂（规则、状态机、约束）？
   ├── NO → 检查系统生命周期
   │         ├── < 2 年 → ❌ 不建议 DDD，用简单 CRUD + Service
   │         └── > 2 年 → ~ 谨慎采用，选择性使用战术模式
   └── YES → 2. 是否有领域专家或稳定的产品负责人？
             ├── NO → ~ 谨慎：没有领域专家的 DDD = 为虚无建模
             └── YES → 3. 团队是否熟悉 DDD 或愿意学习？
                       ├── NO → ~ 从分层架构开始，逐步演进
                       └── YES → ✓ DDD 推荐

适用场景判断表

DDD 带来的核心价值

三层边界划分法

第一层：聚合边界（逻辑边界）
   └── 将紧密关联的实体和值对象组合为聚合，在一个微服务实例内运行
第二层：限界上下文边界（物理边界）
   └── 一个或多个聚合划定在限界上下文内，映射为独立微服务
第三层：域边界
   └── 按核心域/支撑域/通用域分类，分配不同的资源投入策略

避免的误区

DDD 的 5 级演进阶梯

Level 1: Simple Layered (Controller → Service → Repository)
   ↓ 业务规则变复杂
Level 2: DDD 4-Layer with Rich Domain Model
   ↓ 需要多入口 (REST + CLI + MQ + gRPC)
Level 3: Ports & Adapters (Hexagonal Architecture)
   ↓ 读写模式显著分化
Level 4: CQRS — Separate Read/Write Models
   ↓ 需要完整审计追踪 / 时间旅行查询
Level 5: Event Sourcing — Store events, derive state

原则: 不要跨级跳跃。每个级别增加真实复杂度，只有在证明当前级别不够时才升级。

Domain & Subdomain — 领域与子域划分

核心概念

三类子域

如何识别核心域

问三个问题：
1. 这个功能是否是公司的核心竞争力？
2. 用户是否因为这个功能选择我们而非竞品？
3. 如果去掉这个功能，业务是否还能运转？

三个都是 YES → Core Domain
部分是 YES → Supporting
全部是 NO → Generic

资源分配策略

核心域：>60% 资源     → 充血模型 + DDD + 最佳团队
支撑域：20-30% 资源   → 简单 DDD 或外购
通用域：<10% 资源     → 购买/开源 + 最小定制

领域细分流程

4 步分解法

Step 1: 确定研究领域
   └── 明确要解决的业务问题域范围

Step 2: 一级细分 → 子域
   └── 按业务职能分组（如保险 → 承保、理赔、收付、再保）

Step 3: 二级细分 → 子子域
   └── 按流程边界细分（如承保 → 投保、保全、批改）

Step 4: 识别限界上下文
   └── 语义边界 = 限界上下文边界
   └── 一个限界上下文 ≈ 一个微服务

以保险行业为例

保险领域
├── 承保子域 (Core)
│   ├── 投保 (Bounded Context → 微服务)
│   ├── 保全/批改 (Bounded Context → 微服务)
│   └── 核保 (Bounded Context → 微服务)
├── 理赔子域 (Core)
│   ├── 报案 (Bounded Context → 微服务)
│   ├── 查勘 (Bounded Context → 微服务)
│   └── 定损理算 (Bounded Context → 微服务)
├── 收付子域 (Supporting)
│   └── 收付 (Bounded Context → 微服务)
└── 再保子域 (Supporting)
    └── 再保 (Bounded Context → 微服务)

以电商行业为例

电商领域
├── 交易子域 (Core) → 订单、购物车
├── 商品子域 (Supporting) → 商品管理、类目
├── 会员子域 (Generic) → 注册、登录、积分
├── 营销子域 (Core) → 优惠券、促销活动
├── 物流子域 (Supporting) → 发货、签收
└── 支付子域 (Supporting) → 支付、退款

领域细分与微服务拆分的关系

常见错误

Bounded Context — 限界上下文与通用语言

核心概念

通用语言

构建流程

事件风暴 → 团队协商 → 形成统一术语 → 映射到代码

语言映射规则

代码示例

// ✅ 通用语言直接映射到代码
public class Order {                          // 名词：订单
    public void pay(PaymentMethod method) {}  // 动词：支付
    public void cancel(String reason) {}      // 动词：取消
}
// 领域事件命名：OrderPaid, OrderCancelled（过去式）

限界上下文

边界划分流程

1. 事件风暴梳理所有领域对象
2. 按语义一致性聚类对象
3. 识别同一术语在不同语境中的含义差异
4. 划分语义边界 → 即限界上下文
5. 一个限界上下文 ≈ 一个微服务

边界识别信号

示例：电商术语边界

Product BC（商品上下文）:
  "商品" = 带有标题、价格、SKU 的可售卖物品

Order BC（订单上下文）:
  "商品" = 订单中的行项目（快照，价格已固定）

Logistics BC（物流上下文）:
  "商品" = 需要运输的物理货物（货物≠商品）

同一件东西，在不同 BC 中术语和含义不同。每个 BC 内的术语含义唯一。

示例：保险术语边界

上下文映射模式

选择流程图

两个 BC 需要交互吗？
├── NO → Separate Ways
└── YES → 谁主导？
    ├── 平等合作 → Partnership 或 Shared Kernel
    ├── 上游主导 → Customer-Supplier
    └── 下游只能跟随 → Conformist
是否对接外部/遗留系统？
├── YES → ACL (Anti-Corruption Layer)
└── NO → OHS (Open Host Service) + Published Language

限界上下文 → 微服务映射

限界上下文（逻辑边界）
     │
     ▼  映射（考虑以下因素）
     │
微服务（物理边界）

考虑因素：
├── 团队规模与组织结构（康威定律）
├── 技术异构需求
├── 独立部署频率
├── 数据一致性要求
└── 性能与弹性需求

原则: 理论上一个 BC ≈ 一个微服务，但实际需综合考虑。一个 BC 可拆为多个微服务，多个 BC 也可合并为一个微服务。

常见错误

Entity & Value Object — 实体与值对象

对比速查

实体

四种形态

代码模板

// 充血模型：行为在实体内部
public class Order extends AggregateRoot<OrderId> {
    private OrderId id;
    private OrderStatus status;
    private Money totalAmount;

    public void pay() {
        if (!status.canPay()) {
            throw new OrderException("Cannot pay order in " + status);
        }
        this.status = OrderStatus.PAID;
        addDomainEvent(new OrderPaidEvent(this.id));
    }
}

实体与持久化对象的映射

值对象

设计原则

值对象 = 无 ID + 不可变 + 概念完整的属性集合

设计检查：
1. 这个对象是否由属性定义（而非身份）？
2. 修改这个对象的属性是否意味着它是一个不同的东西？
3. 两个实例所有属性相同，是否应该被视为相等？

全部 YES → Value Object

代码示例

// ✅ 不可变值对象
public record Money(BigDecimal amount, Currency currency) {
    public Money add(Money other) {
        if (!this.currency.equals(other.currency)) {
            throw new IllegalArgumentException("Currency mismatch");
        }
        return new Money(this.amount.add(other.amount), this.currency);
    }
}

// ✅ 不可变值对象
public record Address(String province, String city, String district, String street) {
    // 无 setter，无 ID
}

两种代码形态

两种持久化方式

示例对比

-- 方式 1: 属性嵌入
CREATE TABLE person (
    id       BIGINT PRIMARY KEY,
    name     VARCHAR(50),
    province VARCHAR(20),  -- address.province
    city     VARCHAR(20),  -- address.city
    district VARCHAR(20),  -- address.district
    street   VARCHAR(100)  -- address.street
);

-- 方式 2: 序列化大对象
CREATE TABLE person (
    id      BIGINT PRIMARY KEY,
    name    VARCHAR(50),
    address JSON  -- {"province":"...","city":"...","district":"...","street":"..."}
);

实体 vs 值对象 — 决策流程

这是一个领域对象。问：

1. 它需要唯一标识，且标识在其生命周期内保持不变吗？
   ├── YES → 2. 它的状态会随时间改变吗？
   │         ├── YES → Entity
   │         └── NO  → 3. 它是否描述了另一个对象？
   │                   ├── YES → Value Object
   │                   └── NO  → Entity（不可变实体）
   └── NO  → Value Object

快速判断：
  "这是 THE 同一个东西吗？" → Entity（身份比较）
  "这和那个有相同的值吗？" → Value Object（结构相等）

领域建模 vs 数据建模

传统方式（数据建模优先）：
  设计表 → 设计实体 → 每个表一个实体 → 主表关联从表 → 表爆炸

DDD 方式（领域建模优先）：
  领域建模 → 识别 Entity 和 VO → VO 嵌入实体 → 减少表数量 → 简化数据库

常见错误

Aggregate Design — 聚合设计

聚合定义

聚合 = 业务和逻辑紧密关联的实体和值对象的组合，是数据修改和持久化的基本单元。

为什么需要聚合

5 步构建聚合

Step 1: 事件风暴 → 梳理所有实体和值对象
   产出：实体列表（投保单、标的、客户、被保人等）

Step 2: 选出聚合根
   判断标准：
   ├── 是否有独立的生命周期？
   ├── 是否有全局唯一 ID？
   ├── 是否可以创建或修改其它对象？
   └── 是否有专门的模块管理？

Step 3: 按单一职责和高内聚原则，找出与聚合根紧密依赖的实体和值对象
   产出：聚合内对象集合

Step 4: 画引用和依赖模型
   规则：聚合间通过聚合根 ID 关联，不直接引用对象

Step 5: 多个聚合按业务语义归入同一限界上下文

聚合设计 6 原则

聚合大小度量

聚合根职责

聚合根 = 实体 + 管理者 + 对外接口

作为实体：
└── 有自己的属性和业务行为

作为管理者：
└── 协调聚合内实体和值对象按固定规则协同工作

作为对外接口：
└── 聚合间通过聚合根 ID 关联，外部只能通过聚合根访问内部

跨聚合交互规则

正确做法：
  Order.pay() → 生成 OrderPaidEvent
  Inventory.deduct(OrderPaidEvent) → 异步响应

错误做法：
  OrderService.pay() {
      order.setStatus(PAID);       // 直接修改状态
      inventory.deduct(itemId);    // 跨聚合同步调用
  }

常见错误

Aggregate Deep Dive — 聚合设计深度指南

聚合设计 6 原则详解

原则 1：在一致性边界内建模真正的不变条件

不变量 = 无论发生什么操作都必须保持的业务规则

示例：Order 聚合的不变量
├── 订单总金额 = 所有 OrderItem.subtotal 之和
├── PAID 状态的订单不能修改商品
├── CANCELLED 状态的订单不能再支付
└── 同一订单中不能有重复的 SKU

方法: 在聚合根的方法中检查不变量，失败抛异常。

public void pay() {
    if (this.status != OrderStatus.DRAFT) {
        throw new OrderException("Only DRAFT orders can be paid");
    }
    this.status = OrderStatus.PAID;
}

原则 2：设计小聚合

聚合大小 = 直接影响并发性能

过大的后果：
├── 事务锁范围大 → 并发冲突增加
├── 加载全部关联数据 → N+1 查询
├── 修改频率不一致的数据耦合 → 无意义锁等待
└── 重构困难 → 牵一发动全身

拆分决策流程:

当前聚合是否过大？
├── 两个实体是否总是同时修改？
│   ├── 是 → 保留在同一聚合
│   └── 否 → 考虑拆分
├── 聚合内有实体可以独立存在吗？
│   ├── 是 → 拆分为独立聚合
│   └── 否 → 保持
└── 聚合内实体数 > 5？
    ├── 是 → 强烈建议拆
    └── 否 → 保持

原则 3：通过唯一标识引用其他聚合

// ✅ 正确：ID 引用
public class Order {
    private BuyerId buyerId;       // VO，包装 Member BC 的 ID
    private List<OrderItem> items;
}

// ❌ 错误：对象引用
public class Order {
    private Member buyer;          // 直接引用了外部聚合
}

原则 4：在边界之外使用最终一致性

原则 5：通过应用层实现跨聚合服务调用

聚合 A ──事件──→ 聚合 B        ✅ 领域事件解耦
应用服务协调聚合 A + 聚合 B    ✅ 编排层
聚合 A 直接调聚合 B 的领域服务  ❌ 跨聚合耦合

原则 6：适合自己才是最好的

可突破场景：

• 高性能要求 → 可适当放宽一致性约束
• 团队能力限制 → 可先采用简单设计再演进
• 全局事务需求 → 可评估 Saga 或 TCC 方案

聚合根选择指南

候选实体评估：

1. 是否有独立的生命周期？
   例：Order 有 DRAFT→PAID→SHIPPED→DELIVERED 完整生命周期

2. 是否有全局唯一标识？
   例：Order 有 orderId，全局唯一

3. 是否负责创建或修改其他实体？
   例：Order 管理 OrderItem 的添加和移除

4. 是否有专门的模块或团队管理？
   例：有专门的订单模块/订单团队

满足 ≥ 2 个条件 → 适合作为聚合根

大聚合拆分案例

拆分前（问题聚合）

电商核心聚合（过大）：
├── Product (聚合根)
│   ├── SKU (Entity)
│   ├── Category (Entity)
│   ├── Inventory (Entity)
│   ├── Price (Entity)
│   └── Review (Entity)    ← 可以和 Product 分开

拆分后

Product 聚合：
├── Product (聚合根)
├── SKU (Entity)
└── Price (Value Object)

Inventory 聚合：
├── Inventory (聚合根)
└── WarehouseLocation (Value Object)

Review 聚合：
├── Review (聚合根)
└── Rating (Value Object)

关联方式：
Product.id → Inventory.productId (ID 引用)
Product.id → Review.productId (ID 引用)

Domain Events — 领域事件与事件驱动设计

定义与识别

识别关键词

用户/专家口中出现这些句式时 = 领域事件：
├── "当...发生时，则..."    → 支付完成时，生成保单
├── "做完...时，通知..."    → 创建用户后，发送邮件
├── "发生...时，则..."      → 密码输错3次，锁定账户
└── "如果...，那么..."       → 如果审批通过，则通知申请人

为什么用事件而非直接调用

核心原则：一次事务最多修改一个聚合。跨聚合用领域事件实现最终一致性。

事件处理架构

事件构建 → 事件持久化 → 事件总线/消息中间件 → 订阅方接收 → 业务处理

事件实体设计

public abstract class DomainEvent {
    private String eventId;           // 全局唯一ID（UUID）
    private LocalDateTime occurredOn; // 发生时间
    private String eventType;         // 事件类型
    private String sourceAggregate;   // 事件源聚合

    // 业务属性 — 事件发生时的数据快照（不可变，序列化为值对象）
}

事件基本属性

持久化方案

发布方式

同步/异步决策

跨微服务事件示例

投保微服务                    收款微服务                  保单微服务
─────────                    ─────────                  ─────────
生成缴费通知单
  │
  ├─发布→ 缴费通知单已生成 → 订阅收费
  │                            │
  │                         缴费完成
  │                            │
  │←订阅← 缴费已完成 ←────────发布
  │
投保单→保单
  │
  ├─发布→ 保单已生成 ──────────────────────────→ 订阅保存保单

事件总线 (EventBus)

微服务内的事件分发组件：

事件发布 → EventBus
              ├── 微服务内订阅者 → 同步/异步分发到指定聚合
              ├── 微服务外订阅者 → 持久化到事件表 → 异步发消息中间件
              └── 两者都有 → 先发内部，再持久化，再异步发外部

幂等性设计

// 消费者必须实现幂等：同一事件可能被投递多次
public void handle(OrderPaidEvent event) {
    if (eventStore.exists(event.getEventId())) {
        return; // 重复事件，跳过
    }
    // 处理业务逻辑
    eventStore.save(event.getEventId());
}

常见错误

DDD Building Blocks 与命名约定

聚合大小度量表

文件命名约定

domain/
├── order/
│   ├── Order.java        # 聚合根
│   ├── OrderItem.java    # 实体
│   ├── value_objects.java # OrderId, Money, OrderStatus
│   ├── events.java        # OrderCreated, OrderPaid, OrderShipped
│   ├── repository.java    # OrderRepository（接口）
│   ├── services.java      # 领域服务
│   └── errors.java        # OrderException

application/
├── place_order/
│   ├── command.java       # PlaceOrderCommand
│   ├── handler.java       # PlaceOrderHandler
│   └── port.java          # IPlaceOrderUseCase

infrastructure/
├── postgres/
│   ├── order_repository.java  # PostgresOrderRepository
│   └── mappers/
│       └── order_mapper.java  # Domain ↔ DB 映射

六边形端口命名约定

文件命名约定（TypeScript 版）

domain/
├── order/
│   ├── order.ts           # 聚合根
│   ├── order_item.ts      # 实体
│   ├── value_objects.ts   # OrderId, Money 等
│   ├── events.ts          # OrderCreated 等
│   ├── repository.ts      # IOrderRepository
│   ├── services.ts        # 领域服务
│   └── errors.ts          # OrderError 等

application/
├── place_order/
│   ├── command.ts         # PlaceOrderCommand
│   ├── handler.ts         # PlaceOrderHandler
│   └── port.ts            # IPlaceOrderUseCase

infrastructure/
├── postgres/
│   ├── order_repository.ts  # PostgresOrderRepository
│   └── mappers/
│       └── order_mapper.ts  # Domain ↔ DB 映射

依赖规则矩阵

✅ = 可以依赖 ❌ = 不可以依赖

复杂度阶梯速查

Level 1: Simple layered（Controller → Service → Repository）
   ↓ 业务规则变得复杂
Level 2: Domain model（Entities with behavior）
   ↓ 需要多个入口
Level 3: Hexagonal（Ports & Adapters）
   ↓ 读写模式显著分化
Level 4: CQRS（Separate read/write models）
   ↓ 需要完整审计追踪
Level 5: Event Sourcing（Store events, derive state）

不要跳级。每一级增加真实的复杂度。只在证明当前级别不够时才升级。

Entity vs Value Object 速判

Entity or Value Object?
├─ Has unique identity that persists → Entity
├─ Defined only by its attributes    → Value Object
├─ "Is this THE same thing?"         → Entity (identity comparison)
└─ "Does this have the same value?"  → Value Object (structural equality)

Aggregate 边界速判

Aggregate boundaries?
├─ Must be consistent together in a transaction → Same aggregate
├─ Can be eventually consistent                 → Separate aggregates
├─ Referenced by ID only                        → Separate aggregates
└─ >10 entities in aggregate                    → Split it

Domain Service or Entity method? 速判

Does it naturally belong to one entity?
├─ YES → Entity method
└─ NO ↓

Does it require multiple aggregates?
├─ YES → Domain Service
└─ NO ↓

Is it stateless business logic?
├─ YES → Domain Service
└─ NO → Reconsider placement

部分端口位置变体

DDD 为中心的布局：aggregate repository 接口放在 domain/{aggregate}/repository/ 更严格 Hexagonal 布局：所有 driven ports 放在 application/ports/driven/ 两种都可以，关键是依赖仍然指向内，infrastructure 实现而非拥有抽象。

DDD Core Concepts Reference

Detailed explanation of all Domain-Driven Design strategic and tactical patterns.

Strategic Design Patterns

1. Bounded Context (限界上下文)

A bounded context is an explicit boundary within which a domain model exists. Inside the boundary, all terms and concepts have specific, well-defined meanings.

Key Characteristics:

• Each bounded context has its own ubiquitous language
• Models are consistent within the context
• Different contexts may have different models for the same business concept

Example: E-commerce System

Bounded Context: Order Management
  - "Customer" means: buyer with shipping address, payment methods
  - "Product" means: item with price, stock availability

Bounded Context: Customer Relations
  - "Customer" means: person with contact history, support tickets
  - "Product" means: item with warranty info, support documentation

Identifying Bounded Contexts: 1. Listen to how domain experts talk about the business 2. Identify when the same word means different things 3. Look for natural organizational boundaries 4. Find areas that can evolve independently

2. Ubiquitous Language (统一语言)

A language structured around the domain model and used by all team members to connect all activities of the team with the software.

Rules:

• Used in code: class names, method names, variable names
• Used in conversations: team discussions, planning meetings
• Used in documentation: specs, user stories, API docs
• Reflects the business, NOT technical implementation

Example:

BAD (Technical Language):
  OrderService.processPendingOrderStatusUpdate()

GOOD (Domain Language):
  Order.submit()
  Order.confirmPayment()
  Order.cancel(returnReason)

3. Context Mapping (上下文映射)

The relationships and interactions between bounded contexts.

Relationship Patterns:

4. Core Domain / Subdomain Classification

Tactical Design Patterns

1. Entity (实体)

An object defined by its identity, which remains consistent through state changes.

Rules:

• Identity is immutable and unique
• Equality is based on identity, not attributes
• Has a lifecycle (created, modified, archived/deleted)

// Entity: defined by identity
public class Order {
    private OrderId id;        // Identity - NEVER changes
    private OrderStatus status; // Mutable state
    private List<OrderLine> lines;
    
    // Behavior, not just getters/setters
    public void addItem(Product product, Quantity qty) {
        // Business rule: can't add to shipped order
        if (this.status == OrderStatus.SHIPPED) {
            throw new OrderAlreadyShippedException(this.id);
        }
        // ... add logic
    }
}

2. Value Object (值对象)

An object defined by its attributes, with no conceptual identity.

Rules:

• Immutable — create a new instance instead of modifying
• Equality based on all attributes
• Replaceable — entirely replace one value object with another
• Self-validating — validates on construction

// Value Object: defined by attributes
@Value // Lombok: makes it immutable
public class Money {
    BigDecimal amount;
    Currency currency;
    
    public Money add(Money other) {
        if (!this.currency.equals(other.currency)) {
            throw new CurrencyMismatchException();
        }
        return new Money(this.amount.add(other.amount), this.currency);
    }
}

3. Aggregate (聚合)

A cluster of domain objects treated as a single unit.

Rules:

• One aggregate = one transaction boundary
• Reference other aggregates by ID only (not direct object reference)
• The aggregate root is the only entry point
• All invariants within the aggregate must be enforced atomically

Aggregate: Order (Aggregate Root: Order entity)
├── Order (root)
│   ├── orderId: OrderId
│   ├── customerId: CustomerId  ← Reference by ID
│   ├── status: OrderStatus
│   └── totalAmount: Money
├── OrderLine (entity)
│   ├── productId: ProductId    ← Reference by ID
│   ├── quantity: Quantity
│   └── unitPrice: Money
└── ShippingAddress (value object)
    ├── street: String
    ├── city: String
    └── zipCode: String

4. Repository (仓储)

An abstraction for aggregate persistence. One repository per aggregate root.

public interface OrderRepository {
    Optional<Order> findById(OrderId id);
    void save(Order order);
    void delete(Order order);
    List<Order> findByCustomerId(CustomerId customerId);
}

5. Domain Service (领域服务)

A stateless operation that doesn't naturally belong to any entity or value object.

When to use a Domain Service:

• The operation spans multiple aggregates
• The concept doesn't fit as a method on any entity
• Stateless operation

public class PricingService {
    public Money calculateTotal(Order order, List<Discount> applicableDiscounts) {
        // Logic that involves multiple rules, external data
        // Doesn't naturally belong to Order or Discount
    }
}

6. Domain Event (领域事件)

Something meaningful that happened in the domain.

Naming convention: {Aggregate}{Action}Event in past tense

public class OrderPlacedEvent {
    private OrderId orderId;
    private CustomerId customerId;
    private Money totalAmount;
    private Instant occurredAt;
}

public class PaymentConfirmationFailedEvent {
    private OrderId orderId;
    private String failureReason;
    private Instant occurredAt;
}

7. Specification (规约)

An encapsulated business rule that can be combined with others.

public class ActiveOrderSpecification implements Specification<Order> {
    @Override
    public boolean isSatisfiedBy(Order order) {
        return order.getStatus() != OrderStatus.CANCELLED 
            && order.getStatus() != OrderStatus.DELIVERED;
    }
}

public class HighValueOrderSpecification implements Specification<Order> {
    private final Money threshold;
    
    @Override
    public boolean isSatisfiedBy(Order order) {
        return order.getTotalAmount().isGreaterThan(threshold);
    }
}

// Combine specifications
var spec = new ActiveOrderSpecification()
    .and(new HighValueOrderSpecification(new Money("1000", USD)));

The Dependency Rule (CRITICAL)

Infrastructure → Application → Domain
   (adapters)     (use cases)    (core)

Dependencies ALWAYS point inward:
- Infrastructure depends on Application and Domain
- Application depends on Domain
- Domain depends on NOTHING external

Domain layer MUST NOT have dependencies on:

• Database frameworks (JPA, JDBC, MongoDB drivers)
• HTTP libraries (Spring MVC annotations, RestTemplate)
• Messaging (Kafka, RabbitMQ clients)
• Any infrastructure concern

Common Anti-Patterns

DDD Layered Architecture — 四层架构详解

层级与职责

用户接口层 (Interfaces) — DTO, Assembler, Facade
        │
  应用层 (Application) — 编排、事务、权限、事件发布
        │
  领域层 (Domain) — 核心业务逻辑、充血模型
        │  ↑ 接口定义（依赖倒置）
  基础层 (Infrastructure) — Repository实现, Mapper, 消息中间件, 缓存

严格分层 vs 松散分层

推荐严格分层。领域服务变更时只需逐层通知上层，不会遗漏调用方。

三层架构 → DDD 四层演进

传统三层                    DDD 四层
────────                    ───────
表现层 (Controller)  ───→  用户接口层（引入 DTO+Facade）
                              ↓
业务逻辑层 (Service)  ───→  应用层（编排+事务+权限）
                           + 领域层（充血模型+不变量）
                              ↓
数据访问层 (DAO)      ───→  基础层（仓储+依赖倒置）

演进关键变化

依赖倒置 (DIP)

// 领域层 — 定义接口（不依赖任何框架）
package domain.order;
public interface OrderRepository {
    Order findById(OrderId id);
    void save(Order order);
}

// 基础层 — 实现接口
package infrastructure.persistence;
@Repository
public class OrderRepositoryImpl implements OrderRepository {
    private final OrderMapper mapper;
    // 实现...
}

服务编排模式

应用服务 (粗粒度)
  ├── 领域服务A (细粒度)
  │     ├── 实体方法1
  │     └── 实体方法2
  ├── 领域服务B
  │     └── 实体方法3
  └── 仓储接口 (数据持久化)

服务演进

初始：领域服务 a, b, c 各自独立
  ↓ 多次编排后发现 b+c 总是同一组合
优化：合并为新领域服务 (b+c)
  ↓ 应用层编排简化
结果：领域模型越来越精炼

以聚合为单位的架构演进

微服务 1:
├── 聚合 A (热点，拖累整体性能)
├── 聚合 B
└── 聚合 C

演进 ↓

微服务 1:              微服务 2 (独立):
├── 聚合 B              └── 聚合 A (独立部署，独立扩容)
└── 聚合 C

常见错误