DDD on 纪伟的个人博客

领域驱动设计（六）：落地——整洁架构与 .NET 工程结构

Sat, 13 Jun 2026 10:00:00 +0800

写在前面

前五篇讲了 DDD 的"道"——通用语言、战略设计、聚合、实体值对象、领域事件、CQRS。最后这篇讲"术"：这些概念在 .NET 工程里到底怎么放。

答案是一套分层架构——名字很多（整洁架构、洋葱架构、六边形/端口适配器架构），本质就一句话：依赖方向永远向内，领域模型在最中心、不依赖任何人。这篇用 .NET 把它落地，并收口整个 DDD 系列。

这篇的分层结构和微服务系列第八篇（单个微服务的内部结构）是一致的——那里搭的是"一个服务的骨架"，这里补上"DDD 建模在骨架里怎么落地"。

一、为什么需要分层架构

1
2
3
4
5
6
7
8


不分层的痛：
 Controller 直接调 SqlConnection、直接写 SQL、直接 return
 → 业务逻辑散落在 Controller / SQL / 前端 各处
 → 改数据库要动 Controller，改接口要动 SQL
 → 没法测试（测个业务规则还要连数据库）

 根因：职责没分离，依赖方向乱。
 分层架构解决的就是"什么依赖什么"的纪律问题。

二、整洁架构的内核：依赖向内

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


整洁架构（Clean Architecture）/ 洋葱架构 / 六边形架构，本质相同：

 ┌──────────────────────┐
 │ API / UI（最外层） │ 依赖 ↓
 │ ┌──────────────────┐ │
 │ │ Infrastructure │ │ 依赖 ↓
 │ │ ┌────────────┐ │ │
 │ │ │Application │ │ │ 依赖 ↓
 │ │ │ ┌───────┐ │ │ │
 │ │ │ │Domain │ │ │ │ ← 最内，不依赖任何人
 │ │ │ └───────┘ │ │ │
 │ │ └────────────┘ │ │
 │ └──────────────────┘ │
 └──────────────────────┘

 铁律：依赖方向只能"向内"（外层依赖内层，内层绝不依赖外层）

 Domain（领域）在最中心：
 - 只有纯领域逻辑（实体、值对象、聚合、领域事件、接口）
 - 不依赖 EF Core、不依赖 ASP.NET Core、不依赖任何基础设施
 - 是一个"纯 C# 类库"，谁都不认识

 外层认识内层，内层不认识外层。
 → 改数据库、换 Web 框架，领域模型一行不用动。

1
2
3
4


六边形架构（端口与适配器）是同一思想的不同说法：
 端口（Port）= 领域定义的接口（IOrderRepository）
 适配器（Adapter）= 基础设施对接口的实现（EfOrderRepository）
 领域只定义端口，不关心适配器是谁 → 基础设施可替换（六边形的六个边 = 可插拔的适配器）

三、四层职责划分

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


Domain（领域层）—— 最内，纯逻辑
 - 实体、值对象、聚合、聚合根
 - 领域事件、领域服务
 - 仓储接口（IOrderRepository）、其他端口接口
 - 不依赖任何外部框架
 → 前五篇讲的建模，全在这层

Application（应用层）—— 用例编排
 - 命令/查询（CQRS）、用例服务（OrderService）
 - 调用领域层完成业务，调度事务、发事件
 - 定义"应用服务接口"，不关心持久化细节
 → 很薄，只编排，不写业务规则（规则归 Domain）

Infrastructure（基础设施层）—— 技术实现
 - 仓储实现（EfOrderRepository : IOrderRepository）
 - EF Core DbContext、数据库连接
 - 消息队列、缓存、第三方 API 客户端
 - 领域事件的分发器实现、Outbox 投递
 → 所有"脏活累活"和技术细节，全收在这层

API / Presentation（表现层）—— 最外
 - Controller / Minimal API
 - HTTP 入参出参、DTO 与领域对象的转换
 - 认证、异常处理中间件
 → 只做"协议转换"，不含业务逻辑

1
2
3
4
5
6
7
8


依赖关系（编译期引用）：
 API → Application → Domain
 Infrastructure → Application → Domain
 └──（实现 Domain 定义的接口）

 注意：Infrastructure 引用 Domain（为了实现仓储接口），
 但 Domain 不引用 Infrastructure（依赖倒置）。
 这正是"端口在内层定义、适配器在外层实现"的体现。

四、.NET 工程结构

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38


OrderService/ （一个限界上下文 = 一个解决方案）
├── src/
│ ├── OrderService.Domain/ ← 领域层（纯，无框架依赖）
│ │ ├── Aggregates/
│ │ │ └── Orders/
│ │ │ ├── Order.cs （聚合根）
│ │ │ ├── OrderItem.cs （内部实体）
│ │ │ └── OrderStatus.cs
│ │ ├── ValueObjects/
│ │ │ ├── Money.cs Address.cs
│ │ ├── Events/
│ │ │ └── OrderPlaced.cs （领域事件）
│ │ └── Ports/ （端口接口）
│ │ └── IOrderRepository.cs
│ │
│ ├── OrderService.Application/ ← 应用层（编排）
│ │ ├── Commands/ （CQRS 写侧）
│ │ │ └── CancelOrderHandler.cs
│ │ ├── Queries/ （CQRS 读侧）
│ │ │ └── OrderQueryService.cs
│ │ └── Abstractions/
│ │ └── IUnitOfWork.cs
│ │
│ ├── OrderService.Infrastructure/ ← 基础设施（实现）
│ │ ├── Persistence/
│ │ │ ├── EfOrderRepository.cs （实现 Domain 的 IOrderRepository）
│ │ │ └── OrderDbContext.cs （EF Core）
│ │ └── Events/
│ │ └── MediatRDispatcher.cs （领域事件分发）
│ │
│ └── OrderService.Api/ ← 表现层（最外）
│ ├── Program.cs
│ ├── Controllers/
│ │ └── OrdersController.cs
│ └── appsettings.json
└── tests/
 ├── OrderService.Domain.Tests/ ← 领域层测试（纯单元，超快）
 └── OrderService.Application.Tests/ ← 应用层测试

五、各层代码长什么样

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


// Domain：纯领域，不认识 EF Core / ASP.NET Core
namespace OrderService.Domain.Orders;

public class Order : Entity<OrderId>, IAggregateRoot
{
 public OrderStatus Status { get; private set; }
 public void Cancel(string reason)
 {
 if (Status >= OrderStatus.Shipped)
 throw new DomainException("已发货不能取消");
 Status = OrderStatus.Cancelled;
 }
}
// Domain 层定义端口（接口），不关心实现
public interface IOrderRepository { Task<Order?> Find(OrderId id, CancellationToken ct); }

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// Application：编排，薄
namespace OrderService.Application.Commands;
public class CancelOrderHandler(IOrderRepository repo, IUnitOfWork uow)
{
 public async Task Handle(CancelOrderCommand cmd, CancellationToken ct)
 {
 var order = await repo.Find(cmd.OrderId, ct) ?? throw new NotFoundException();
 order.Cancel(cmd.Reason); // 业务规则在领域层
 await uow.SaveChangesAsync(ct); // 不关心是 EF 还是别的
 }
}

1
2
3
4
5
6
7


// Infrastructure：实现端口（依赖倒置）
namespace OrderService.Infrastructure.Persistence;
public class EfOrderRepository(OrderDbContext db) : IOrderRepository // 实现 Domain 接口
{
 public Task<Order?> Find(OrderId id, CancellationToken ct)
 => db.Orders.FirstOrDefaultAsync(o => o.Id == id, ct);
}

1
2
3
4
5
6
7


// API：协议转换，无业务逻辑
app.MapPut("/orders/{id}/cancel", async (OrderId id, CancelRequest req,
 CancelOrderHandler h, CancellationToken ct) =>
{
 await h.Handle(new(id, req.Reason), ct);
 return Results.NoContent();
});

六、防贫血：业务逻辑回归领域层

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


整洁架构落地最容易跑偏的点：贫血模型

 贫血（错）：Order 只有属性，规则写在 CancelOrderHandler 里
 → Handler 变成"事务脚本"，领域层形同虚设
 → 规则分散、难测、难复用

 充血（对）：规则在 Order.Cancel() 内部
 Handler 只负责"加载→调用→保存"，不掺合规则
 → 规则内聚、可单测、可复用

 落地纪律：应用层只编排，业务规则一律下沉到领域层。
 问自己："这段逻辑，放实体方法里是不是更合适？"

七、可测试性：分层最大的红利

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


领域层是纯 C#、无依赖 → 单元测试极快、极简单
（呼应我的《.NET 单元测试》系列）

[Fact]
public void Cancel_Should_Throw_When_Shipped()
{
 var order = Order.Place(NewId(), AnyAddress(), [Line(Money(99), 1)]);
 order.MarkShipped();

 var act = () => order.Cancel("误操作");

 act.Should().Throw<DomainException>("已发货不能取消");
}
// 不连数据库、不起 Web 服务器、毫秒级跑完
// 因为领域层不依赖任何基础设施，测试就是 new 对象 + 断言

1
2
3
4


这正是分层 + 依赖倒置的核心回报：
 - 领域规则可以被快速、确定性地测试
 - 基础设施（EF、HTTP）可以被替换/打桩
 - 这就是《.NET 单元测试（四）：依赖注入与可测试性》的实战价值

八、DDD 系列小结

六篇 DDD，一条主线：

（一）全景：通用语言是灵魂；战略（限界上下文）重于战术
（二）聚合：一致性边界；四原则——小聚合、ID 引用、一事务一聚合、内部强一致
（三）实体与值对象：身份 vs 值；优先用值对象；强类型 ID
（四）领域事件：事实解耦；可靠投递用 Outbox；事件溯源按需
（五）CQRS：读写分家；事件投影同步；按痛点渐进落地
（六）落地：整洁架构，依赖向内，领域在中心，可测试是最大红利

DDD 的核心心法，其实就三条：

先理解业务（通用语言、限界上下文）——比任何技术细节都重要
把规则关进聚合（一致性边界、充血模型）——让代码自我保护
用事件解耦（领域事件、最终一致、CQRS）——应对复杂与规模

九、回到整个架构系列

把 DDD 放回更大的架构图景里：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


微服务系列（单体→云原生）回答"系统怎么拆、怎么通信、怎么一致、怎么观测"
DDD 系列（业务怎么建模）回答"拆开的边界里、领域怎么设计"

两者交汇点：
 限界上下文 = 微服务/模块的拆分单位
 聚合边界 = 事务/一致性边界
 领域事件 = 事件驱动/最终一致的载体
 整洁架构 = 每个服务内部的工程骨架

 → 战略设计决定系统怎么拆（架构）
 → 战术设计决定拆开的单元怎么建（DDD）
 → 二者合一，才是"业务复杂度可控、技术可演进"的完整答案。

架构没有终点。不管你最终选单体还是微服务、用不用事件溯源、上不上 CQRS，理解业务、忠实建模、控制一致性边界、用事件解耦——这些原则永远适用。这才是这两个系列想留给你的东西。

领域驱动设计（五）：CQRS——读写分离与领域模型

Fri, 12 Jun 2026 10:00:00 +0800

写在前面

前三篇把"写"这一侧讲透了——实体、值对象、聚合、领域事件，都是围绕"怎么正确地变更业务状态"。但真实系统里，读和写的负载往往完全不对称：写要严谨一致，读要快、要灵活、要多形态。用同一个模型硬扛两边，两头不讨好。

这就是 CQRS（Command Query Responsibility Segregation，命令查询职责分离） 要解决的。这篇从 DDD 的视角讲 CQRS——它和领域事件、事件溯源是天然搭档。

这篇和微服务系列第五篇是互补关系：那篇从"数据一致性"角度讲 CQRS 解决最终一致；这篇从"领域建模"角度讲 CQRS 怎么把读写模型分开。

一、CQRS 的本质

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


传统：一个模型既读又写（CRUD 一把梭）
 Order 实体 + OrderRepository + OrdersController
 → 写要校验、要维护不变量、要走聚合根
 → 读要 JOIN、要排序、要返回 DTO、要支持各种查询
 → 一个模型被两种截然不同的需求拉扯，越来越臃肿

CQRS：把"写"和"读"拆成两套模型

 写侧（Command） 读侧（Query）
 ──────────────── ────────────────
 命令处理 查询服务
 领域模型（聚合） 读模型（DTO/物化视图）
 仓储 只读数据源
 强一致、校验、规则 快、灵活、可反规范化

1
2
3
4


一句话：CQRS 不是技术，是"承认读写不一样，别硬凑一起"的设计观。

 来源：Bertrand Meyer 的 CQS 原则（命令查询分离：方法要么改状态，要么返回值，不兼得）
 CQRS 把它从"方法级"放大到"架构级"——整个系统的读写分开。

二、为什么要分离

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


写（Command）的真实诉求：
 ✓ 严格校验业务规则（不能超卖、余额够不够）
 ✓ 维护不变量（聚合一致性）
 ✓ 强一致（一个事务一个聚合）
 ✓ 领域模型要"对"，要可维护
 → 频率通常不高（用户操作）

读（Query）的真实诉求：
 ✓ 快（缓存、索引、反规范化）
 ✓ 灵活（各种筛选/排序/聚合查询）
 ✓ 多形态（列表页/详情页/报表，各有 DTO）
 ✓ 高并发（一次列表查 N 条，QPS 远高于写）
 → 频率通常很高（浏览、搜索）

 一个模型同时满足"严格校验"和"高速查询"，本质矛盾。
 分开后，各自优化到极致。

三、写侧：领域模型

1
2
3
4
5
6
7
8


写侧 = DDD 的主战场（前三篇的内容）

 入口：命令（PlaceOrderCommand、CancelOrderCommand）
 处理：应用服务 → 加载聚合 → 调聚合方法 → 保存 → 发事件
 模型：聚合根（带完整不变量校验）
 存储：仓储，按聚合根整体存取

 写侧不关心"页面要显示什么"，只关心"变更是否合法"。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


// 写侧：命令处理（领域模型驱动）
public sealed record CancelOrderCommand(OrderId OrderId, string Reason);

public class OrderCommandHandler
{
 private readonly IOrderRepository _repo;
 private readonly IUnitOfWork _uow;
 private readonly IDomainEventDispatcher _events;

 public async Task Handle(CancelOrderCommand cmd, CancellationToken ct)
 {
 var order = await _repo.Find(cmd.OrderId, ct) ?? throw new NotFoundException();
 order.Cancel(cmd.Reason); // 聚合内校验 + 收集事件
 await _repo.Save(order, ct);
 await _uow.SaveChangesAsync(ct);
 await _events.DispatchAsync(order.DequeueEvents(), ct); // 通知读侧更新
 }
}

四、读侧：读模型

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


读侧 = 为"查询"优化的模型，不管业务规则

 特征：
 - 反规范化（denormalized）：把需要的字段拍平，免 JOIN
 - 直接返回 DTO，不经过领域模型
 - 可以用完全不同的存储（关系库宽表 / Redis / Elasticsearch）
 - 不校验业务规则（读而已）

 一个"订单列表"读模型可能是：
 OrderListItemDto { OrderId, CustomerName, Total, Status, PlacedOn }
 → 已经 JOIN 好客户名，列表查询一次搞定
 而"订单详情"又是另一个读模型，各取所需。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


// 读侧：直接查、直接返 DTO，不碰领域模型
public class OrderQueryService
{
 private readonly IDbConnection _db; // Dapper 直接查读库

 public Task<IReadOnlyList<OrderListItemDto>> ListByCustomer(CustomerId cust, CancellationToken ct)
 => _db.QueryAsync<OrderListItemDto>(@"
 SELECT o.id AS OrderId, c.name AS CustomerName,
 o.total AS Total, o.status AS Status, o.placed_on AS PlacedOn
 FROM order_list_view o JOIN customers c ON c.id = o.customer_id
 WHERE o.customer_id = @cust", new { cust });

 // 详情、报表……各有各的读模型，互不干扰
}

public sealed record OrderListItemDto(
 Guid OrderId, string CustomerName, decimal Total, string Status, DateTime PlacedOn);

1
2
3
4
5


读侧自由度极高：
 - 不走聚合根（读不修改，没必要）
 - 不走仓储（仓储是为"整体存取聚合"设计的，读不需要）
 - 可以直接 SQL / Dapper / 查 ES / 读 Redis
 → 读侧就是"怎么快怎么来"，领域规则是写侧的事。

五、数据同步：读模型怎么跟写侧一致

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


写侧一更新，读侧怎么同步？用领域事件投影。

 写侧 Order 状态变了 → 发 OrderCancelled 事件
 → 读侧投影器（Projector）订阅 → 更新对应的读模型表
 → 读侧最终一致

 读模型表（投影）：
 order_list_view ← 订单列表用
 order_detail_view ← 订单详情用
 customer_orders_view ← 按客户聚合的视图
 每个视图由各自的事件投影维护。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


// 读侧投影器：监听领域事件，更新读模型
public class OrderListProjector
{
 private readonly IDbConnection _db;
 public async Task On(OrderPlaced e, CancellationToken ct)
 {
 await _db.ExecuteAsync(@"
 INSERT INTO order_list_view (id, customer_id, total, status, placed_on)
 VALUES (@OrderId, @CustomerId, @Total, 'Placed', @OccurredOn)", e);
 }
 public async Task On(OrderCancelled e, CancellationToken ct)
 {
 await _db.ExecuteAsync(
 "UPDATE order_list_view SET status='Cancelled' WHERE id=@OrderId", e);
 }
}

1
2
3
4
5


所以前面四篇是层层铺垫：
 实体/值对象/聚合 → 写侧的领域模型
 领域事件 → 写侧通知读侧的渠道
 CQRS → 读写两侧正式分家，事件是同步纽带
 这就是 DDD 的完整闭环。

六、CQRS + 事件溯源

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


CQRS 和事件溯源是黄金搭档（但可独立使用）：

 事件溯源（第四篇）：写侧存"事件流"，状态由重放得到
 CQRS（本篇）：读写分离

 合体：
 写侧：命令 → 聚合 → 存事件流（Event Store）
 读侧：事件 → 投影 → 读模型（Materialized View）

 ┌─────────┐ 事件 ┌───────────┐ 投影 ┌──────────┐
 │ 写侧 │ ──────→ │ 事件存储 │ ─────→ │ 读模型 │ ← 查询
 │ (聚合) │ │ (Event │ │ (宽表/ES)│
 └─────────┘ │ Store) │ └──────────┘
 └───────────┘

 价值：写侧有完整审计（事件流），读侧极致优化（投影）
 两者解耦，各自演进。

 代价：复杂。只有读多写少 + 强审计需求才值得。
 普通 CRUD，单独用 CQRS 都未必需要，更别说加事件溯源。

七、什么时候用 CQRS（和什么时候别用）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


值得用 CQRS：
 ✓ 读写负载严重不对称（读 >> 写）
 ✓ 查询复杂、多形态（列表/详情/报表差异大）
 ✓ 需要独立扩容读侧（读加缓存、加副本，写保持单库）
 ✓ 已用领域事件，顺势做投影（边际成本低）

不要用 CQRS：
 ✗ 简单 CRUD（读写都很简单，分离只增复杂度）
 ✗ 读和写模型差异不大
 ✗ 团队没准备好维护"两套模型 + 同步"

 铁律：CQRS 是用"复杂度"换"读写各自优化"。
 只有读写矛盾真的痛，才划得来。

1
2
3
4
5
6
7


渐进式落地：
 1. 先把写侧领域模型建好（前三篇）
 2. 读侧仍用同一套库，但用独立查询服务 + DTO（轻量 CQRS）
 3. 哪个读场景扛不住了，单独给它建投影读模型
 4. 读量真的大，再引入独立读存储（Redis/ES）

 不要一上来就全套 CQRS + 事件溯源，按痛点逐步推进。

八、小结

CQRS 本质：承认读写需求不同，命令（写）和查询（读）分家
写侧：命令 → 领域模型（聚合），严格校验、强一致（前三篇内容）
读侧：为查询优化的读模型（反规范化 DTO），不经领域模型，怎么快怎么来
同步纽带：领域事件投影——写侧发事件，读侧投影更新读模型（最终一致）
CQRS + 事件溯源：黄金搭档但复杂，按需组合
何时用：读写严重不对称 / 查询复杂多形态；简单 CRUD 别用
渐进落地：先领域模型，再独立查询服务，再按痛点加投影，最后才上独立读存储
闭环：实体/值对象/聚合（写模型）+ 领域事件（纽带）+ CQRS（读写分家）= DDD 完整架构

最后一篇，把这些落到工程结构——整洁架构与 .NET 项目分层。

领域驱动设计（四）：领域事件与事件溯源——用事件驱动业务

Thu, 11 Jun 2026 10:00:00 +0800

写在前面

聚合设计有个铁律：一个事务只改一个聚合。那"下单后要扣库存、加积分、发通知"这种跨聚合的联动怎么办？答案就是——领域事件（Domain Event）。

聚合做完自己的事，发一个事件声明"发生了什么"，至于谁来响应、怎么响应，它一概不管。这种解耦是 DDD 和微服务架构的黏合剂。这篇讲领域事件，并引出它的进阶玩法——事件溯源（Event Sourcing）。

这篇和微服务系列第五篇（数据一致性）是一对：那篇讲"事件如何可靠跨服务投递（Outbox）"，这篇讲"事件本身怎么设计、怎么用"。

一、领域事件是什么

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


领域事件：领域中"已经发生、业务关心"的事。

 特征：
 - 过去式命名（OrderPlaced、PaymentReceived、ItemShipped）
 → "已下单""已付款""已发货"，是事实，不是请求
 - 不可变（发生过的事不能改）
 - 自描述（带够重建上下文所需的信息）

 价值：解耦
 聚合 A 完成变更 → 发事件
 聚合 B/C/D 各自订阅，独立响应
 A 不需要知道有谁在听、有几个、在哪

1
2
3
4
5
6
7


为什么用"过去式"：
 OrderPlaced（订单已创建）—— 事实，谁都不能撤销
 PlaceOrder（去下单）—— 这是"命令"，不是事件

 事件 = 已经发生的客观事实 → 订阅者只能反应，不能拒绝
 命令 = 要求做某事 → 可以被拒绝（余额不足、库存不够）
 两者别混（下一节细讲）。

二、事件 vs 命令

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


命令（Command）：表达"意图"，可被拒绝
 名字：动词原形 / 祈使（PlaceOrder、CancelOrder）
 方向：外部 → 领域
 结果：可能成功，可能失败（业务规则不允许）
 例：用户点"下单" → 发 PlaceOrder 命令 → 系统校验，成功则订单创建

事件（Event）：表达"事实"，不可拒绝
 名字：过去式（OrderPlaced、OrderCancelled）
 方向：领域 → 外部
 结果：已成事实，订阅者只能据此反应
 例：订单创建后 → 发 OrderPlaced → 库存扣减、积分、通知据此触发

 链条：
 命令 PlaceOrder →（校验通过）→ 订单创建 + 事件 OrderPlaced
 → 订阅者据此发新命令（如 ReserveStock）→ 成功 + StockReserved
 → ... 一个业务的完整流程 = 命令与事件交替推进

三、领域事件的设计

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34


// 领域事件基类
public interface IDomainEvent
{
 DateTime OccurredOn { get; }
}

// 具体事件：过去式 + 自描述（带够订阅者需要的信息）
public sealed record OrderPlaced(
 OrderId OrderId,
 CustomerId CustomerId,
 IReadOnlyCollection<OrderLine> Lines,
 Address ShippingAddress,
 Money Total,
 DateTime OccurredOn
) : IDomainEvent;

public sealed record OrderCancelled(OrderId OrderId, string Reason, DateTime OccurredOn)
 : IDomainEvent;

// 聚合根内：变更完成后"收集"事件，由外部统一分发
public class Order : Entity<OrderId>, IAggregateRoot
{
 private readonly List<IDomainEvent> _events = new();
 public IReadOnlyCollection<IDomainEvent> DequeueEvents()
 { var e = _events.ToList(); _events.Clear(); return e; }

 public void Cancel(string reason)
 {
 if (Status >= OrderStatus.Shipped)
 throw new DomainException("已发货不能取消");
 Status = OrderStatus.Cancelled;
 _events.Add(new OrderCancelled(Id, reason, DateTime.UtcNow)); // 只收集，不直接处理
 }
}

1
2
3
4
5
6


设计要点：
 1. 事件是 record（不可变）+ 过去式命名
 2. 带够信息：订阅者不该为了处理事件再去回查聚合
 （但也不必塞全部字段，按订阅者需要）
 3. 聚合只"收集"事件，不直接处理（保持聚合纯净、可测）
 4. 事件的分发由应用层统一做（下一节）

四、进程内事件分发

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


// 应用层：保存聚合后，把收集到的事件分发出去
public class OrderService
{
 private readonly IOrderRepository _repo;
 private readonly IDomainEventDispatcher _dispatcher;

 public async Task CancelAsync(OrderId id, string reason, CancellationToken ct)
 {
 var order = await _repo.Find(id, ct) ?? throw new NotFoundException();
 order.Cancel(reason); // 聚合内变更 + 收集事件
 await _repo.Save(order, ct); // 先持久化（保证数据落库）

 foreach (var evt in order.DequeueEvents())
 await _dispatcher.DispatchAsync(evt, ct); // 再分发
 }
}

// 分发器：可以用 MediatR（进程内发布/订阅的标准选择）
public sealed record OrderCancelledHandler(IInventoryService Inventory)
 : INotificationHandler<OrderCancelledNotification>
{
 public Task Handle(OrderCancelledNotification n, CancellationToken ct)
 => Inventory.ReleaseAsync(n.OrderId, ct); // 库存释放
}

1
2
3
4
5


关键顺序：先存库，再分发
 如果先分发再存库：事件处理了，但聚合没存上 → 不一致
 所以一定 先 Save 聚合 → 再 Dispatch 事件

 进程内的同步分发，简单可靠，但有个隐患（下一节）。

五、可靠投递：跨进程用 Outbox

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


进程内分发的隐患：
 聚合存了 ✅ → 分发事件时崩了 ❌
 → 库存没释放、积分没加，事件丢了

 跨服务（微服务）更严重：事件要发到消息队列，队列和网络都可能失败。

 解决方案：Outbox 模式（微服务系列第五篇讲过）
 1. 聚合变更 + 事件记录，写进同一个数据库事务（原子）
 2. 一个独立 worker 轮询 outbox 表，把事件投递到消息队列
 3. 投递成功标记已发送；失败重试

 → 业务操作和事件发布，获得 ACID 级别的原子性。
 → 跨服务的领域事件，必须走 Outbox，否则一定会丢。

六、事件溯源（Event Sourcing）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


传统持久化：存"当前状态"
 订单表：status=Shipped, total=299
 → 只知道"现在是什么"，历史丢了（怎么变到这一步的？不知道）

事件溯源：存"导致状态变化的所有事件"
 事件流：
 OrderPlaced(total=299)
 PaymentReceived(amount=299)
 OrderShipped(carrier=SF)
 → "当前状态" = 把事件流从头"重放"计算出来

 订单的当前状态，就是按顺序应用这些事件得到的结果。
 完整历史永久保留：能回溯到任意时间点、能审计、能做时态查询。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


事件溯源的好处：
 ✓ 完整审计轨迹（发生了什么，一清二楚）
 ✓ 时态查询（"上周三这个订单是什么状态？"）
 ✓ 和 DDD 天然契合（领域事件本就是"发生的事"）
 ✓ 模型与存储解耦（存事件，状态是派生的）

事件溯源的代价：
 ✗ 复杂度飙升（重放、快照、版本演进、并发）
 ✗ 查询难（要查"当前所有已发货订单"得重放全部 → 需要读侧投影，第五篇 CQRS）
 ✗ 事件 schema 演进困难（老事件怎么重放？）

 结论：大多数业务不需要事件溯源。
 只在"强审计/合规/时态"需求（金融、计费、医疗）才值得上。
 别因为"看起来高级"就用。

6.1 一个最小示意

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


// 事件流持久化（伪代码）
public interface IEventStore
{
 Task AppendAsync(OrderId id, IEnumerable<IDomainEvent> events, int expectedVersion, CancellationToken ct);
 Task<IReadOnlyList<IDomainEvent>> LoadAsync(OrderId id, CancellationToken ct);
}

// 重建聚合：重放事件流
public class OrderRepository
{
 private readonly IEventStore _store;
 public async Task<Order?> Find(OrderId id, CancellationToken ct)
 {
 var events = await _store.LoadAsync(id, ct);
 if (events.Count == 0) return null;
 var order = new Order(); // 空聚合
 foreach (var e in events) order.Apply(e); // 逐个重放
 return order;
 }
}

// 聚合内的 Apply：根据事件设置状态（不校验，因为是已发生的事实）
public class Order
{
 public void Apply(IDomainEvent e)
 {
 switch (e)
 {
 case OrderPlaced p: Id = p.OrderId; Status = OrderStatus.Placed; Total = p.Total; break;
 case PaymentReceived: Status = OrderStatus.Paid; break;
 case OrderShipped: Status = OrderStatus.Shipped; break;
 case OrderCancelled: Status = OrderStatus.Cancelled; break;
 }
 }
}

1
2
3
4


快照（Snapshot）：重放太慢的优化
 每 N 个事件存一个"状态快照"
 重建时：从最近快照开始 + 重放之后的少量事件
 → 长事件流的聚合才需要，先别过度设计。

七、何时用领域事件 / 事件溯源

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


领域事件：强烈推荐，几乎必用
 ✓ 跨聚合解耦（聚合不直接调聚合）
 ✓ 副作用隔离（通知、积分、统计 = 订阅者，不污染核心）
 ✓ 跨服务异步协作（配 Outbox）

事件溯源：谨慎，按需
 ✓ 金融/计费/医疗等强审计场景
 ✗ 普通 CRUD 业务（用状态持久化就够）
 ✗ 团队没准备好应对复杂度

 事件 ≠ 事件溯源。
 用领域事件解耦，是基本操作；
 用事件溯源存状态，是高级选项，别混为一谈。

八、小结

领域事件：已发生的事实，过去式命名，不可变，自描述
事件 vs 命令：命令=意图可拒绝（外部→领域）；事件=事实不可拒绝（领域→外部）
设计：事件用 record，带够信息；聚合只"收集"事件，分发交给应用层
顺序：先持久化聚合，再分发事件（保证一致）
可靠投递：跨进程/跨服务必须走 Outbox（业务与事件同事务）
事件溯源：存事件流而非当前状态；审计强但复杂度高，按需采用
关键认知：领域事件（解耦，必用）≠ 事件溯源（存状态，慎用）

下一篇讲 CQRS——读写分离架构，和领域事件/事件溯源天然搭档。

领域驱动设计（三）：实体与值对象——建模积木的选择

Wed, 10 Jun 2026 10:00:00 +0800

写在前面

上一篇讲聚合时反复出现两个角色——实体（Entity） 和 值对象（Value Object）。它们是领域建模的最基础积木，但很多开发者只会用实体，把"值对象"这个被严重低估的工具晾在一边。

这篇把它们讲清：什么时候该用实体、什么时候该用值对象、怎么用 .NET 实现、怎么映射到数据库。掌握值对象，你的模型会干净一大截。

一、核心区别：身份 vs 值

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


实体（Entity）：靠"身份"区分
 有唯一 ID，属性变了还是它
 判等：ID 相同就是同一个
 例：订单 Order（有 OrderId）、用户 Customer
 问："这是哪一个？" → 实体

值对象（Value Object）：靠"值"区分
 没有 ID，所有属性相同就相等
 不可变（改 = 换新对象）
 例：地址 Address、金额 Money、日期范围 DateRange
 问："这是多少/什么样的？" → 值对象

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


一个判断技巧：
 两个"完全一样"的东西，是两个还是同一个？

 两张一模一样的 100 元 → 是同一个"金额"（值对象 Money）
 （你不在乎是哪张钞票，只在乎面值）
 两个同名同姓的用户 → 是两个不同的用户（实体 Customer）
 （你在乎"是哪一位"）

 在乎"是哪一个" → 实体
 不在乎、只在乎"值是什么" → 值对象

二、优先用值对象

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


经验法则：能用值对象，就别用实体。

 值对象的好处：
 ✓ 不可变 → 天然线程安全、无副作用
 ✓ 按值判等 → 测试和比较简单
 ✓ 无身份管理 → 不用操心 ID 生成、生命周期
 ✓ 自带校验 → 构造时即合法（金额不能负、邮箱要合规）
 ✓ 组合性强 → 小值对象拼出大概念

 实体是"有状态、有生命周期"的东西，是少数。
 现实中大多数概念其实是值对象，只是被误建成了实体。

 典型误建：
 Address 做成有 AddressId 的实体 → 没必要，地址就是值
 Money 做成实体 → 金额就是值
 只有一个数量字段的"积分记录" → 可能是值

三、值对象的 .NET 实现

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


// 推荐：用 record / record struct，自动实现"不可变 + 按值判等"
public readonly record struct Money(decimal Amount, string Currency)
{
 // 构造时校验：保证"创建即合法"
 public Money
 {
 if (Amount < 0) throw new DomainException("金额不能为负");
 if (string.IsNullOrWhiteSpace(Currency))
 throw new DomainException("必须指定币种");
 }

 public Money Add(Money other)
 {
 if (Currency != other.Currency)
 throw new DomainException("币种不同，不能相加");
 return this with { Amount = Amount + other.Amount }; // 返回新对象
 }

 public Money Multiply(int times) => this with { Amount = Amount * times };
}
// 用法：
// var price = new Money(99m, "CNY");
// var total = price.Multiply(3); // 新对象，price 不变
// price == new Money(99m, "CNY") // true（按值判等）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


// 复杂值对象用 record（class），可包含多字段和行为
public sealed record Address(
 string Province, string City, string Detail, string Zip)
{
 public string FullText => $"{Province}{City}{Detail}（{Zip}）";
 public bool IsDomestic => Zip.StartsWith("1") || /* … */;
}

// 日期范围：典型值对象，不可变 + 自带规则
public sealed record DateRange(DateTime Start, DateTime End)
{
 public DateRange
 {
 if (End < Start) throw new DomainException("结束不能早于开始");
 }
 public bool Overlaps(DateRange other) =>
 Start < other.End && other.Start < End;
 public TimeSpan Duration => End - Start;
}

1
2
3
4


值对象实现三要点：
 1. 不可变（record 自动；class 的话所有 setter private/无 setter）
 2. 按值判等（record 自动；class 要重写 Equals/GetHashCode）
 3. 构造即校验（在构造函数/record 的 init 校验上下文里校验）

四、实体的 .NET 实现

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34


// 实体基类：提供 ID 与按 ID 判等
public abstract class Entity<TId> where TId : notnull
{
 public TId Id { get; protected set; } = default!;
 public override bool Equals(object? obj) =>
 obj is Entity<TId> other && EqualityComparer<TId>.Default.Equals(Id, other.Id);
 public override int GetHashCode() => Id.GetHashCode();
}

// 实体：有身份、有状态流转
public class Customer : Entity<CustomerId>
{
 public CustomerName Name { get; private set; } // 用值对象装字段
 public Email Email { get; private set; } // 用值对象
 public CustomerStatus Status { get; private set; }

 private readonly List<Address> _addresses = new(); // 值对象集合
 public IReadOnlyCollection<Address> Addresses => _addresses.AsReadOnly();

 public Customer(CustomerId id, CustomerName name, Email email) : base()
 {
 Id = id;
 Name = name ?? throw new DomainException("姓名必填");
 Email = email ?? throw new DomainException("邮箱必填");
 Status = CustomerStatus.Active;
 }

 public void ChangeEmail(Email newEmail)
 {
 if (Status == CustomerStatus.Closed)
 throw new DomainException("已注销客户不能改邮箱");
 Email = newEmail;
 }
}

1
2
3
4
5


实体要点：
 - 继承 Entity<TId>，按 ID 判等（不是按所有字段）
 - 状态流转通过方法（ChangeEmail），不暴露 setter
 - 字段尽量用值对象包装（CustomerName / Email），而非裸 string
 → 裸 string "abc" 不是合法邮箱；Email 值对象构造即校验

五、强类型 ID（标识类型）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


痛点：
 public void Transfer(Guid fromAccountId, Guid toAccountId, decimal amount)
 → fromAccountId 和 toAccountId 都是 Guid，传反了编译器不报错！

强类型 ID：给每个 ID 套一层类型
 public readonly record struct AccountId(Guid Value);
 public readonly record struct CustomerId(Guid Value);

 void Transfer(AccountId from, AccountId to, Money amount)
 → 传反了？类型不匹配，编译直接报错。
 → 顺手解决了"裸 Guid 满天飞、容易传错"的经典 bug。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


public readonly record struct AccountId(Guid Value)
{
 public static AccountId New() => new(Guid.NewGuid());
 public override string ToString() => Value.ToString();
}

public class Account : Entity<AccountId>, IAggregateRoot
{
 public Money Balance { get; private set; }
 public void Withdraw(Money amount)
 {
 if (amount.Amount > Balance.Amount)
 throw new DomainException("余额不足");
 Balance = Balance.Add(amount with { Amount = -amount.Amount });
 }
}
// 调用：Transfer(new AccountId(...), new AccountId(...), money)
// —— 两个参数类型都是 AccountId，但位置固定，传错编译报错

六、映射到数据库（EF Core）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


// 实体 → 表
modelBuilder.Entity<Order>(b =>
{
 b.HasKey(o => o.Id);
 b.Property(o => o.Status).HasConversion<string>();

 // 聚合内的子实体（订单项）：同一个聚合，一起存取
 b.OwnsMany(o => o.Items, item =>
 {
 item.WithOwner().HasForeignKey("OrderId");
 item.HasKey("Id");
 item.Property(i => i.Price).HasConversion(
 m => m.Amount, v => new Money(v, "CNY"));
 });
});

// 值对象 → Owned Entity（值对象没有自己的表身份，归属宿主）
modelBuilder.Entity<Customer>(b =>
{
 b.OwnsOne(c => c.Name); // CustomerName 作为宿主的一列/几列
 b.OwnsOne(c => c.Email);
 b.OwnsMany(c => c.Addresses); // 值对象集合 → 关联表
});

// 强类型 ID → 转换为底层类型存储
modelBuilder.Entity<Account>(b =>
{
 b.Property(a => a.Id).HasConversion(
 id => id.Value, v => new AccountId(v));
});

1
2
3
4
5
6
7


EF Core 映射心智模型：
 实体（聚合根、子实体）→ 有主键 → 表/行
 值对象 → 无独立身份 → OwnsOne（单值）/ OwnsMany（集合）→ 宿主的列或子表

 关键：值对象不该有自己的 DbSet（它不独立），
 子实体的仓储也归聚合根（OrderItem 不单独存取）。
 这与第二篇"按聚合根整体存取"一致。

七、一张速查表

1
2
3
4
5
6
7
8
9


场景 用实体还是值对象
──────────────────────────────────────────────────────
订单、用户、账户（有生命周期） 实体
收货地址、金额、坐标 值对象
邮箱、手机号、用户名 值对象（自带格式校验）
日期范围、时间段 值对象
订单项（依附订单存在） 子实体（在聚合内，不独立）
订单项里的"单价" 值对象（Money）
两个"完全相同"是否算同一个 是→值对象；否→实体

八、小结

核心区别：实体靠身份（ID）判等，值对象靠值判等
判断技巧：在乎"是哪一个"→ 实体；只在乎"值是什么"→ 值对象
优先值对象：不可变、按值判等、构造即合法、组合性强——被低估的工具
.NET 实现：值对象用 record/record struct；实体继承 Entity<TId>
强类型 ID：给 ID 套类型，根治"裸 Guid 传错"的 bug
EF Core：实体→表/行；值对象→OwnsOne/OwnsMany（无独立身份）；按聚合根整体存取
字段尽量值对象化：Email 比 string 安全得多

下一篇讲领域事件与事件溯源——聚合做完自己的事后，怎么用事件驱动整个系统。

领域驱动设计（二）：聚合设计精讲——一致性边界的艺术

Tue, 09 Jun 2026 10:00:00 +0800

写在前面

上一篇做了 DDD 全景导览，提到聚合（Aggregate）是 DDD 最关键、也最容易用错的概念。这篇就把它彻底讲透。

很多人把聚合理解成"一组相关的对象"——这只对了一半。聚合真正的灵魂是四个字：一致性边界。理解了这四个字，你才知道怎么划聚合、聚合根该干什么、为什么一个事务只能改一个聚合。

一、为什么需要聚合

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


没有聚合会怎样？

 一个订单 Order，里面有若干订单项 OrderItem。
 如果没有边界规则：
 - 谁都能 new 一个 OrderItem 塞进去
 - 谁都能改 OrderItem 的数量、价格
 - 订单总价 = 各项小计之和，这个规则谁来保证？

 结果：
 → 任何一处漏改，总价就算错（不变量被破坏）
 → 业务规则散落各处，谁也不敢动
 → 并发修改互相覆盖

 聚合要解决的，就是"怎么让一组对象的规则不被绕过"。

1
2
3
4
5


聚合的本质：
 把"必须一起保持一致"的对象圈起来，
 指定一个入口（聚合根），
 所有修改只能从入口进，
 规则在入口内部强制，外界绕不过去。

二、聚合与聚合根的定义

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


聚合（Aggregate）
 一组作为整体被访问和持久化的领域对象。
 它是一个"一致性边界"——边界内的对象，在任何时刻都满足业务规则。

聚合根（Aggregate Root）
 聚合的入口对象，是外部访问聚合的唯一通道。
 - 聚合外部的代码，只能持有聚合根的引用
 - 不能直接引用聚合内部的子对象
 - 所有对内部的修改，必须经过聚合根的方法

 例：订单聚合
 Order（聚合根）
 ├── OrderItem（内部实体）
 └── ShippingAddress（内部值对象）

 外部代码：
 order.AddItem(...) ✅ 经过聚合根
 order.Items[0].Qty = 5 ❌ 绕过聚合根直接改内部

三、聚合根的职责

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


聚合根要承担四件事：

 1. 守门人
 所有修改入口都在它身上（AddItem / Cancel / Ship ...）
 内部对象不暴露可变状态（返回只读集合、值对象不可变）

 2. 不变量维护者
 业务规则在聚合根方法内部强制
 例：总价 = Σ小计；库存≥0；状态只能正向流转
 → 任何修改完成后，聚合一定处于"合法"状态

 3. 身份与标识
 持有聚合的唯一 ID（OrderId）
 外部对聚合的引用，只用 ID，不持有对象

 4. 领域事件的发布者
 完成一次合法修改后，发出领域事件
 （例：OrderPlaced）供外部订阅

四、聚合设计四原则

这是整篇的核心，背下来。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


原则 1：尽量设计小聚合
 错：把 User + 所有 Order + 所有 Review 塞进"用户聚合"
 → 改一个评论要锁整个用户，并发灾难
 对：聚合只包含"必须一起变更"的对象
 Order 聚合 = Order + OrderItem；Review 单独一个聚合
 越小越好，一个聚合根 + 少量子对象是理想形态。

原则 2：跨聚合引用，只引用 ID
 Order 持有 CustomerId，不持有 Customer 对象
 → 解耦，避免加载一个聚合时拖出整张对象图
 → 需要客户信息？另查，或读侧投影（第五篇 CQRS 讲）

原则 3：一个事务只修改一个聚合
 跨聚合的变更 → 用领域事件 + 最终一致，不在一个事务里硬保
 → 这就是微服务系列第五篇 Saga / 事件驱动的由来
 → 聚合边界 = 事务边界 = 一致性边界（三位一体）

原则 4：内部强一致，跨聚合最终一致
 聚合内：规则立即满足（强一致）
 聚合间：通过事件异步对账（最终一致）

五、怎么划聚合边界（试金石）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


判断一组对象是不是该在一个聚合里，用这个问题：

 "这几个对象，是否必须在一个事务里一起改，才能保证正确？"

 是 → 同一个聚合
 否 → 拆成不同聚合，用事件联动

 举例验证：
 Order 和 OrderItem：
 改订单项数量，必须同时重算订单总价 → 同一聚合 ✅
 Order 和 Customer：
 下单时记录客户即可，改订单不影响客户 → 不同聚合（用 CustomerId）✅
 Order 和 Inventory：
 下单要扣库存，但"扣库存"是库存聚合自己的事
 → 不同聚合，用 OrderPlaced 事件通知库存聚合 ✅
 Order 和 Payment：
 支付是独立的，订单只关心"是否已支付"
 → 不同聚合，事件联动 ✅

1
2
3
4
5


一个常被问的问题：订单项算实体还是聚合？
 OrderItem 有自己的 ID，是"实体"，
 但它离开订单没有意义（没有"游离的订单项"），
 所以它不是独立聚合，而是 Order 聚合的内部实体。
 → 有 ID ≠ 是聚合。是否独立可被外部直接访问，才决定它是不是聚合根。

六、聚合的加载与持久化

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


聚合作为一个整体被存取：

 加载：一次把整个聚合（聚合根 + 子对象）从库里捞出来
 保存：一次把整个聚合写回

 仓储（Repository）按"聚合根"建，不按"表"建：
 IOrderRepository.Save(order) // 存整个订单（含订单项）
 IOrderRepository.Find(orderId) // 取整个订单

 EF Core 里：一个聚合根对应一个 DbSet，子对象用 Owned / 导航属性一起加载。
 → 不要为 OrderItem 单独建仓储/DbSet（它不独立）。

七、并发控制

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


多个请求同时改一个聚合，怎么不互相覆盖？

 首选：乐观锁（版本号）
 聚合带一个 Version 字段
 UPDATE ... WHERE Id = ? AND Version = ?
 → 有人在 你 之后 改过？Version 变了，你的更新影响 0 行 → 冲突，重试或报错

 为什么乐观锁够用：
 聚合边界小，冲突概率低
 而且我们坚持"一事务一聚合"，锁的范围本来就小

 EF Core：[Timestamp] / IsRowVersion() 自动生成乐观锁

八、完整 .NET 示例

把上面所有原则落到一个订单聚合上：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76


// 强类型 ID（避免基础类型误用）
public readonly record struct OrderId(Guid Value);
public readonly record struct ProductId(Guid Value);

// 聚合根
public class Order : Entity<OrderId>, IAggregateRoot
{
 private readonly List<OrderItem> _items = new();
 public IReadOnlyCollection<OrderItem> Items => _items.AsReadOnly();
 public OrderStatus Status { get; private set; }
 public Address ShippingAddress { get; private set; }
 private int _version; // 乐观锁版本号

 // 仓储加载/EF Core 用，不对外
 private Order(OrderId id, Address shipTo) : base(id)
 {
 Status = OrderStatus.Draft;
 ShippingAddress = shipTo;
 }

 // 工厂：创建即合法（保证不变量）
 public static Order Place(OrderId id, Address shipTo, IEnumerable<(ProductId, Money, int)> lines)
 {
 var order = new Order(id, shipTo);
 foreach (var (pid, price, qty) in lines)
 order.AddItem(pid, price, qty); // 复用规则
 if (!order._items.Any())
 throw new DomainException("订单至少要有一项");
 order.Status = OrderStatus.Placed;
 return order;
 }

 // 所有修改入口：内部强制不变量
 public void AddItem(ProductId product, Money price, int qty)
 {
 if (Status != OrderStatus.Draft)
 throw new DomainException("非草稿态不能加项");
 if (qty <= 0) throw new DomainException("数量必须 > 0");
 if (price.Amount <= 0) throw new DomainException("价格必须 > 0");

 var existing = _items.FirstOrDefault(i => i.ProductId == product);
 if (existing is not null) existing.Increase(qty); // 内部实体也只暴露方法
 else _items.Add(new OrderItem(product, price, qty));
 }

 public void Cancel()
 {
 if (Status >= OrderStatus.Shipped)
 throw new DomainException("已发货不能取消");
 Status = OrderStatus.Cancelled;
 // 发领域事件（第四篇展开）
 AddDomainEvent(new OrderCancelled(Id));
 }

 // 派生值：不变量的体现，不存储
 public Money Total => _items.Aggregate(
 new Money(0m, _items[0].Price.Currency),
 (sum, i) => sum.Add(i.SubTotal));
}

// 内部实体：不独立、不对外，只通过聚合根改
public class OrderItem : Entity<Guid>
{
 public ProductId ProductId { get; }
 public Money Price { get; }
 public int Qty { get; private set; }
 public Money SubTotal => new(Price.Amount * Qty, Price.Currency); // 派生

 internal void Increase(int n) // internal，外部调不到
 {
 if (n <= 0) throw new DomainException("增量必须 > 0");
 Qty += n;
 }
}

public enum OrderStatus { Draft, Placed, Paid, Shipped, Cancelled }

1
2
3
4
5
6
7
8


这段代码体现了全部原则：
 - 聚合根守门：_items 私有，只暴露 AsReadOnly，外部改不了
 - 不变量：AddItem 内校验数量/价格/状态；Total 永远 = Σ小计
 - 工厂保证创建即合法（空订单建不出来）
 - 内部实体 OrderItem 的修改方法 internal，只能被聚合根调
 - 跨聚合用 ID：OrderId/ProductId，不持有对方对象
 - 领域事件：Cancel 后发 OrderCancelled，不直接去改别的聚合
 - 乐观锁：_version 字段

九、常见错误

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


错误 1：大聚合（God Aggregate）
 把所有相关对象塞一个聚合 → 锁大、并发差、加载慢
 → 回到原则 1：小聚合，跨聚合用 ID + 事件

错误 2：贫血聚合
 聚合根只有 getter/setter，规则写在 Service 里
 → 不变量形同虚设。规则必须在聚合根方法内。

错误 3：跨聚合事务
 为了"图省事"，一个事务改订单+库存+积分
 → 破坏一致性边界，回到分布式事务地狱
 → 跨聚合坚决用最终一致

错误 4：直接暴露内部集合
 public List<OrderItem> Items { get; } → 外部 order.Items.Clear() 绕过规则
 → 返回 IReadOnlyCollection，或私有 + 显式方法

错误 5：按表建聚合/仓储
 OrderItem 单独建仓储 → 它不独立，违反"整体存取"
 → 仓储按聚合根建

十、小结

聚合 = 一致性边界：把必须一起变更的对象圈起来，规则内部强制
聚合根是唯一入口：守门、维护不变量、持身份、发事件
四原则：小聚合、跨聚合用 ID、一事务一聚合、内部强一致跨聚合最终一致
划界试金石：是否必须一个事务一起改？是→同聚合，否→拆开用事件
持久化：按聚合根整体存取，仓储对应聚合根而非表
并发：乐观锁（版本号）足够，因为坚持一事务一聚合
五大错误：大聚合、贫血、跨聚合事务、暴露内部集合、按表建仓储

下一篇讲建模的基础积木——实体与值对象：怎么选、怎么用 .NET 实现、怎么映射到数据库。

领域驱动设计（一）：战略设计与战术设计全景

Mon, 08 Jun 2026 10:00:00 +0800

写在前面

在微服务系列第三篇里，我讲服务拆分时反复提到一个词——限界上下文，它就来自 DDD（Domain-Driven Design，领域驱动设计）。当时埋了个伏笔，这篇就来把它讲透。

DDD 不是一种技术，而是一套应对复杂业务的方法论：怎么把真实世界的业务，忠实地映射成代码模型。很多人觉得 DDD 玄学，是因为一上来就扎进"实体、值对象、聚合"这些战术名词。其实 DDD 分两层——战略设计（拆分边界）比战术设计（建模积木）重要得多。

这篇是 DDD 系列第一篇，做全景导览。后续会单独深入聚合设计、事件风暴落地等。

一、DDD 要解决什么问题

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


软件失败的头号原因：不是技术选错，是"把业务理解错了"

 现实：业务专家说一套，开发理解一套，代码实现又一套
 → 三者逐渐分裂，代码越来越偏离业务真相
 → 改一个需求，发现代码里的概念和业务对不上
 → 最后系统变成"能跑但没人敢动"的黑洞

 DDD 的核心目标：让"业务知识"顺畅地流进"代码模型"
 → 业务专家和开发说同一种话（通用语言）
 → 代码结构忠实反映业务结构（领域建模）
 → 复杂度被控制在边界内（限界上下文）

 一句话：DDD 是关于"理解业务"的工程方法论。

1
2
3
4
5


什么时候该上 DDD：
 ✓ 业务复杂、规则多、领域知识深厚（金融、电商核心、ERP）
 ✗ CRUD 为主、逻辑简单的系统 → 用 DDD 是杀鸡用牛刀

 DDD 的代价不低，只有业务复杂度配得上时才值得。

二、通用语言（Ubiquitous Language）

DDD 的第一块基石，也是最容易被忽视的。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


通用语言：业务专家和开发共用同一套词汇

 反例（没有通用语言）：
 业务说"客户"，代码里叫 User
 业务说"下单"，代码里叫 createOrder
 业务说"退款"，代码里叫 handleReturn
 → 沟通要 constantly 翻译，翻译就会失真

 通用语言：
 业务说的每个术语 = 代码里的类/方法/字段名
 "客户" 就是 Customer，"下单" 就是 placeOrder
 → 沟通零翻译，代码读起来像业务文档

 怎么建立：业务专家和开发一起，把核心概念逐一命名、统一，
 写进文档、写进代码、写进测试。 disagreements 当场解决。

通用语言是 DDD 的灵魂。没有它，后面的实体、聚合都是空中楼阁——因为你自己都不知道在建模什么。

三、战略设计：划分边界

战略设计回答"系统怎么切"。这是 DDD 价值最大的部分。

3.1 领域与子域

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


领域（Domain）：你的业务范围（如"电商"）
子域（Subdomain）：领域内的子问题，分三类：

 核心子域（Core） —— 你的竞争优势，最复杂，最值得投入
 电商的：定价、促销、推荐
 → 自研，倾注最好的设计和人才

 支撑子域（Supporting）—— 必要但非差异化
 电商的：库存、物流
 → 可自研可采购，够用就行

 通用子域（Generic） —— 谁都需要，无差异化
 电商的：认证、权限、通知
 → 直接用现成方案，别自研

 精力分配：核心域 > 支撑域 > 通用域
 常见错误：在通用域上花大力气自研，核心域反而草草了事。

3.2 限界上下文（Bounded Context）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


限界上下文：一个模型成立的"边界范围"

 同一个词，在不同上下文里含义不同：
 "商品"
 商品上下文：上架的 SKU（详情、图片、分类）
 订单上下文：下单时的快照（当时的价格、规格）
 配送上下文：要发货的物理货品（重量、体积、库位）
 → 三个"商品"，三个上下文，三套模型。不能硬塞进一个 Product 类。

 限界上下文 = 模型的自治边界：
 - 内部有统一的通用语言
 - 内部模型自洽，不污染别的上下文
 - 对外提供清晰的业务能力

 价值：它天然就是"模块/微服务"的拆分单位
 （详见微服务系列第三篇：服务拆分第一性原理）

3.3 上下文映射（Context Mapping）

划清上下文后，还要理清它们之间怎么协作。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


常见的上下文关系：

 合作关系（Partnership）：两个上下文团队紧密协作，共同设计
 → 适合无法明确划分责任的场景

 共享内核（Shared Kernel）：两个上下文共享一小块核心模型
 → 共享部分强耦合，改动要双方同意。慎用，容易退化成大泥球。

 客户-供应商（Customer-Supplier）：上游供应，下游消费
 → 上游优先，但要照顾下游需求。明确谁是甲方。

 防腐层（Anti-Corruption Layer，ACL）：下游建一层翻译
 → 防止上游（尤其是遗留系统）的烂模型"腐蚀"自己的干净模型
 → 接入第三方/老系统时的标准做法，极其重要。

 开放主机服务（OHS）/ 发布语言（PL）：上游提供标准开放接口
 → 对外用一套稳定协议，屏蔽内部实现

 实战中最有用：ACL（防腐层）—— 任何接外部/遗留系统的地方都该建。

四、战术设计：建模积木

战略设计画好边界后，在单个上下文内部用战术积木来建模。这些是 DDD 最出名的名词，但记住：它们服务于战略，不是 DDD 的全部。

4.1 实体（Entity）

1
2
3
4
5
6
7


有"身份标识"（ID），即使属性全变，还是它自己。

 例：订单 Order，有 OrderId
 → 改了收货地址、改了状态，它还是"那一笔订单"
 → 两个 Order 即使所有字段相同，ID 不同就是两笔

 特征：有唯一 ID、有生命周期、靠 ID 判等

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


// 实体：靠 Id 判等，不靠属性
public class Order : Entity // Entity 基类提供 Id 与判等
{
 public OrderId Id { get; }
 public CustomerId CustomerId { get; private set; }
 public OrderStatus Status { get; private set; }
 public Address ShippingAddress { get; private set; }

 public void ChangeShipping(Address newAddress)
 {
 if (Status == OrderStatus.Shipped)
 throw new DomainException("已发货不能改地址");
 ShippingAddress = newAddress;
 }
}

4.2 值对象（Value Object）

1
2
3
4
5
6
7
8


没有身份，靠"属性的值"判等。不可变。

 例：地址 Address、金额 Money、坐标 Point
 → 两个 "北京市朝阳区" 是同一个地址，无需 ID 区分
 → 改地址 = 换一个新对象，不修改原对象（不可变）

 特征：无 ID、不可变、按值判等、通常很小
 价值：被严重低估。能用值对象就别用实体，能省掉大量 ID 管理。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


// 值对象：不可变，按值判等（两个金额相同就相等）
public readonly record struct Money(
 decimal Amount, string Currency)
{
 public Money Add(Money other)
 {
 if (Currency != other.Currency)
 throw new DomainException("币种不同");
 return this with { Amount = Amount + other.Amount };
 }
}
// 用法：var total = price.Add(tax); // 不改原对象，返回新的

4.3 聚合与聚合根（Aggregate & Aggregate Root）—— DDD 的核心

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


聚合：一组紧密相关的对象，作为一个"一致性边界"整体被访问。

 聚合根：聚合的入口对象，外部只能通过它访问聚合内部。

 例：订单聚合
 Order（聚合根）
 ├── OrderItem（订单项，若干）
 └── ShippingAddress（收货地址，值对象）

 规则：
 - 外部不能直接 new OrderItem 或直接拿 OrderItem 改
 - 必须通过 Order.AddItem(...) / Order.RemoveItem(...)
 - 订单项只在自己所属的订单上下文里有意义

 聚合保证的"不变量"（Invariants）：
 例：订单总价 = 所有订单项小计之和
 库存不能为负
 → 这些规则由聚合根在内 部强制维护，外界绕不过去

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


// 聚合根：所有不变量在内部强制，外部无法绕过
public class Order : Entity, IAggregateRoot
{
 private readonly List<OrderItem> _items = new();
 public IReadOnlyCollection<OrderItem> Items => _items;
 public Money Total => _items.Aggregate(
 new Money(0, Currency), (sum, i) => sum.Add(i.SubTotal));

 public void AddItem(ProductId product, Money price, int qty)
 {
 if (Status != OrderStatus.Draft)
 throw new DomainException("非草稿态不能加项");
 if (qty <= 0)
 throw new DomainException("数量必须大于 0");

 var existing = _items.FirstOrDefault(i => i.ProductId == product);
 if (existing is not null) existing.Increase(qty);
 else _items.Add(new OrderItem(product, price, qty));
 // 不变量由聚合根维护，外部拿不到 _items 直接改
 }
}

聚合是 DDD 最关键也最容易用错的概念，第五节专门讲设计原则，后续会有整篇展开。

4.4 领域服务、领域事件、仓储、工厂

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


领域服务（Domain Service）
 承载"不属于任何单个实体"的业务逻辑
 例：转账 = 涉及两个账户，不该塞进某一个 Account
 → 封装成 TransferService.Transfer(from, to, amount)
 特征：无状态、纯领域逻辑

领域事件（Domain Event）
 记录"领域中发生的事"，用于解耦
 例：OrderPlaced（订单已创建）→ 触发扣库存、加积分、发通知
 → 聚合做完自己的事，发事件，订阅者各自反应
 → 微服务系列第五篇讲过：这是事件驱动 + 最终一致的基础

仓储（Repository）
 聚合的"存取接口"，屏蔽持久化细节
 对外提供 IOrderRepository.Find(id) / Save(order)
 实现在基础设施层（EF Core / Dapper），领域层只认接口
 → 一个聚合对应一个仓储，按"聚合根"整体存取，不按表

工厂（Factory）
 封装复杂对象的创建（保证创建时就满足不变量）
 简单创建用构造函数/静态工厂；复杂聚合用专门的 Factory

五、聚合设计原则（最容易踩的坑）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


1. 尽量设计小聚合
 错误：把"用户、订单、商品、评价"塞进一个大"用户聚合"
 → 一改全锁，性能差、并发冲突多
 正确：一个聚合 = 一致性边界，只包含必须一起变更的

2. 跨聚合引用用 ID，不用对象引用
 Order 引用 CustomerId，不直接持有 Customer 对象
 → 解耦，避免一个聚合加载整张图

3. 一个事务只修改一个聚合
 跨聚合的变更 → 用领域事件 + 最终一致（不靠一个事务硬保）
 → 这就是微服务系列第五篇 Saga / 事件驱动的由来

4. 不变量在聚合内部强一致，跨聚合最终一致
 核心：聚合边界 = 事务边界 = 一致性边界（三位一体）

 判断聚合边界的试金石：
 "这几个对象，必须在一个事务里一起改才能保证正确吗？"
 是 → 同一聚合；否 → 拆成不同聚合，用事件联动。

六、DDD 落地的常见误区

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


误区 1：贫血模型（Anemic Model）
 实体只有 getter/setter，业务逻辑全写在 Service 里
 → 实体退化成数据袋，丢失了"封装不变量"的精髓
 → 这其实是"事务脚本"，不是 DDD

误区 2：为 DDD 而 DDD
 简单 CRUD 系统硬套聚合/仓储/领域事件
 → 复杂度暴涨，收益为零。CRUD 就老老实实 CRUD。

误区 3：战略缺失，只剩战术
 不画限界上下文，直接开始抠实体值对象
 → 战术在错误的边界里建模，比不用 DDD 还糟

误区 4：大聚合
 什么都往一个聚合塞，变成分布式时代的"巨型对象"

误区 5：仓储当 DAO 用
 按"表"建仓储（UserRepository 对应 User 表）
 → 仓储应该按"聚合根"建，整体存取，不是按表 CRUD

七、DDD 与微服务、分层架构的关系

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


DDD 不是孤岛，它和前面讲的所有架构概念是一体的：

 战略设计（限界上下文）
 = 微服务的拆分单位（微服务系列第三篇）
 = 模块化单体的模块边界（系列第二篇）

 领域事件
 = 事件驱动 / 最终一致的基础（系列第五篇）
 = Outbox 模式投递的内容

 聚合边界 = 事务边界 = 一致性边界
 = 数据一致性的设计起点（系列第五篇）

 仓储 + 接口隔离
 = 整洁架构/洋葱架构的核心（系列第八篇 .NET 落地）

 防腐层 ACL
 = 服务间通信的解耦手段（系列第六篇）

 → DDD 是"粘合剂"，把前面散落的架构概念，在"业务建模"层面统一起来。
 → 这也是为什么把它放在架构系列里讲。

八、小结

DDD 的目标：让业务知识忠实流进代码模型，应对复杂业务
通用语言是灵魂：业务和代码说同一套话，术语即类名
战略设计 > 战术设计：领域/子域（核心/支撑/通用）、限界上下文、上下文映射（尤其防腐层）
战术积木：实体（有 ID）、值对象（按值/不可变）、聚合 + 聚合根（一致性边界）、领域服务/事件/仓储/工厂
聚合四原则：小聚合、跨聚合用 ID 引用、一事务一聚合、内部强一致跨聚合最终一致
五大误区：贫血模型、为 DDD 而 DDD、战略缺失、大聚合、仓储当 DAO
DDD 是粘合剂：战略上下文 = 微服务边界；领域事件 = 最终一致基础；聚合 = 一致性边界

下一篇会深入聚合设计——怎么划聚合边界、聚合根该承担什么、跨聚合如何协作，附完整 .NET 代码。

后端架构实战（三）：服务拆分的第一性原理——按领域切，不是按技术切

Sat, 30 May 2026 10:00:00 +0800

写在前面

上一篇讲到，模块化单体的关键是画对边界，而真正的边界是数据边界。这一篇就把这个问题彻底说透：服务（或模块）到底该按什么切？

这是整个架构系列里最关键的一篇。拆分边界画错了，比不拆还惨——因为错误边界上的每一次跨服务调用，都是一次跨网络的分布式事务。

一、三种常见的拆分思路

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


思路 A：按技术层切（最常见、最错误）
 用户服务 = 所有用户的 Controller/Service/Dao
 ── 错。这是把单体里的"层"竖着切了，制造了一堆跨层网络调用。

思路 B：按数据表切
 订单服务 = 订单表相关的一切
 ── 接近正确，但只看数据不看业务，容易切碎。

思路 C：按业务领域切（正确答案）
 订单服务 = "下单"这个业务能力涉及的全部（代码 + 数据）
 ── 这就是 DDD（领域驱动设计）的限界上下文。

二、为什么不能按技术层切

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


按技术层切的灾难：

 假设拆成：Controller 服务、Service 服务、DAO 服务
 一次"下单"要跨 3 个服务调用：
 API → Controller 服务 → Service 服务 → DAO 服务 → DB

 问题：
 ✗ 一次业务操作 = 3 次网络往返（慢）
 ✗ 任意一层挂了，整个链路挂（脆弱）
 ✗ 改一个业务规则要动 3 个服务（没解耦）
 ✗ 事务跨 3 个服务（分布式事务地狱）

 本质：技术层是"同一个业务的不同实现细节"，
 把实现细节切成独立服务，是把内部的刀子变成了网络上的刀子。

铁律：服务的边界必须沿着业务能力切，绝不能沿着技术分层切。

三、按领域切：DDD 限界上下文

领域驱动设计（DDD）给出了正确的拆分单位——限界上下文（Bounded Context）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


限界上下文 = 一个业务子领域的"自治范围"

 在这个范围内：
 - 有自己的领域模型（术语、实体、规则）
 - 有自己的数据
 - 对外提供清晰的业务能力接口

 电商的典型限界上下文：
 - 订单上下文（下单、支付、退款）
 - 商品上下文（上架、库存、SKU）
 - 用户上下文（注册、登录、资料）
 - 配送上下文（发货、物流、签收）

 每个"上下文"就是一个天然的模块/服务候选。

3.1 怎么找限界上下文

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


方法 1：事件风暴（Event Storming）
 把业务流程里发生的"领域事件"全列出来
 （订单已创建、已支付、已发货……）
 按相关性聚类 → 一簇事件 ≈ 一个上下文

方法 2：语言分析法
 同一个词在不同语境下含义不同，就是上下文边界
 例："商品"
 - 在商品上下文：是指上架的 SKU（有详情、图片）
 - 在订单上下文：是指下单时的快照（有当时价格）
 - 在配送上下文：是指要发货的物理货品（有重量、体积）
 → 三个"商品"，属于三个上下文，不能硬塞一个模型。

3.2 一个概念，多个模型

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


新手错误：追求"一个全局统一的 User/Product 模型"
 → 模型越塞越大，字段来自所有部门，谁都改不动。

DDD 的正确姿势：每个上下文只保留自己需要的视图

 User 在「用户上下文」：id, 手机号, 密码, 注册时间
 User 在「订单上下文」：id, 收货地址, 会员等级（折扣用）
 User 在「配送上下文」：id, 收货地址, 联系电话

 字段不重复冗余存储？不——必要时冗余（下一篇数据一致性会讲）
 关键是：模型是上下文私有的，不互相污染。

四、拆错了的代价

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


错误拆分的典型症状（出现这些，说明边界画错了）：

 ✗ 跨服务调用密集
 一个请求要链式调 5、6 个服务 → 拆得太碎或边界错了

 ✗ 共享数据库
 多个服务读写同一张表 → 边界根本没切干净

 ✗ 频繁的分布式事务
 动不动就要保证"跨服务的数据一致" → 这些本该在一个服务内

 ✗ 改一个需求要动多个服务
 本来一个模块内的改动，被迫协调多个团队

 ✗ 服务间循环依赖
 A 调 B，B 又调 A → 边界划分反了

判断边界好坏的最简单标准：高频一起变更的东西，应该在同一个服务里。变更频率和方向的耦合度，是验证边界的试金石。

五、拆分粒度：多大算合适

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


太大：一个服务干所有事 → 退回单体（但有了网络成本）
太小：每个 API 一个服务 → "纳米服务"，运维灾难

 实用经验：

 1. 能由"一个小团队（2~3 人 Pizza Team）独立负责"为一个单位
 → 这就是"两个披萨团队"原则的由来

 2. 一个业务能力（动词）对应一个服务，而不是一个名词
 "订单管理"是好服务名；"订单表"不是

 3. 先粗后细
 先按大领域切 4~6 个粗粒度服务，
 跑稳了，哪个真的扛不住再二次拆分。
 一次拆太细几乎必然拆错。

 4. 别为了"扩容"拆服务
 扩容可以用多实例解决（无状态水平扩展），
 不需要靠拆服务。拆服务是为了"解耦"，不是"扩容"。

六、一个实战例子

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


电商"下单"流程，看正确边界怎么让事情变简单：

 错误边界（按技术层 / 按表）：
 下单 = 调「订单服务」+「库存服务」+「价格服务」+「优惠券服务」
 全程分布式事务，任何一个失败都要回滚，痛苦。

 正确边界（按领域聚合）：
 下单逻辑收敛在「订单上下文」内部：
 - 查商品快照、扣库存、算价格 都在订单服务内（同库事务）
 - 只在"成功后"异步通知「库存」「积分」服务（最终一致）
 一次本地事务搞定核心，周边用事件解耦。

 区别：
 核心交易 → 强一致，收敛在一个服务内
 周边副作用（积分、通知、统计）→ 异步、最终一致

这就引出第五篇的核心：核心数据强一致收敛在服务内，跨服务用最终一致性。

七、小结

三种拆法：按技术层（错）、按表（接近）、按领域（对）
铁律：服务边界沿业务能力切，绝不沿技术分层切
DDD 限界上下文：业务子领域的自治范围，是天然的拆分单位
一概念多模型：每个上下文只保留自己需要的视图，不要追求全局统一模型
边界好坏的试金石：高频一起变更的，应在同一服务；出现密集跨服务调用/共享库/循环依赖，说明拆错了
粒度：一个小团队能独立负责为单位，先粗后细，别为扩容而拆

下一篇算一笔明白账：微服务的"分布式税"——拆服务之后，你到底要为哪些隐性成本买单。