Architecture 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 代码。

后端架构实战（八）：落地——用 ASP.NET Core 搭一个微服务骨架

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

写在前面

前七篇全是道理：权衡、单体、拆分、分布式税、一致性、通信、可观测性。这一篇把理论落成代码——用 ASP.NET Core 搭一个最小可用的微服务骨架。

它不会是一个完整生产系统，但会覆盖微服务的"承重墙"：项目结构、依赖注入、API 网关、健康检查、弹性（Polly）、可观测性（OpenTelemetry）。每一处都对应前面某一篇讲过的道理。

前置：本篇假设你读过我的《ASP.NET Core 学习笔记》系列（中间件管道、DI、认证授权）。基于 .NET 8 LTS。

一、整体结构

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


一个最小微服务系统（4 个工程）：

 Gateway/ API 网关（YARP，统一入口、路由、鉴权）
 OrderService/ 订单服务（业务 A）
 InventoryService/ 库存服务（业务 A 的依赖）
 Shared/ 共享内核（契约、公共类型）

 对应前文：
 拆分（第三篇）→ 按领域切 Order / Inventory
 通信（第六篇）→ 网关 + 服务间 HTTP
 分布式税（第四篇）→ 健康检查、Polly 弹性
 可观测性（第七篇）→ OpenTelemetry 串联

1
2
3
4
5
6
7
8


工程依赖方向（单向，严禁循环）：
 Gateway ──→ Shared
 OrderService ──→ Shared
 InventoryService ──→ Shared
 OrderService ──调用──→ InventoryService（运行时 HTTP，非编译依赖）

 关键：服务间运行时依赖走网络，编译期互不引用
 → 这样才能独立编译、独立部署。

二、每个服务的内部分层

单个服务内部，按职责分层（不是按"被拆成服务"的技术层——区别于第三篇的反模式）：

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


OrderService/
├── OrderService.Api/ 表现层（Controller / 最小 API）
│ └── 引用 Application、Domain
├── OrderService.Application/ 应用层（用例、编排、接口定义）
│ └── 引用 Domain
├── OrderService.Domain/ 领域层（实体、领域服务、规则）
│ └── 不依赖任何人（依赖倒置的核心）
└── OrderService.Infrastructure/ 基础设施（DB、外部调用、实现）
 └── 引用 Application（实现接口）

 依赖方向永远向内，Domain 在最中心、不依赖任何层。
 这是"整洁架构/洋葱架构"的思路，保证领域逻辑纯净。

三、依赖注入：组装一切

ASP.NET Core 的 DI 是一等公民（见我的 ASP.NET Core 笔记一）。微服务里，所有跨层依赖都通过 DI 注入，这样才好测试、好替换。

 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


// OrderService.Application/Dependencies.cs
public static class Dependencies
{
 public static IServiceCollection AddOrderServices(this IServiceCollection services)
 {
 // 应用层服务
 services.AddScoped<IOrderService, OrderService>();
 // 端口适配器：接口在 Application，实现在 Infrastructure
 services.AddScoped<IInventoryClient, InventoryClient>();
 services.AddScoped<IOrderRepository, OrderRepository>();
 return services;
 }
}

// OrderService.Api/Program.cs
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddOrderServices(); // 业务服务
builder.Services.AddControllers();
builder.Services.AddHealthChecks(); // 健康检查（第五节）
builder.Services.AddHttpClientPolicies(); // Polly 弹性（第六节）

var app = builder.Build();
app.MapControllers();
app.MapHealthChecks("/health"); // 暴露健康检查端点
app.Run();

单元测试里可以替换 IInventoryClient 为 mock，这就是第四篇《.NET 单元测试：依赖注入与可测试性》的价值。

四、API 网关：YARP 统一入口

对外不直连各服务，用网关收口（第六篇）。.NET 生态用 YARP（Yet Another Reverse Proxy，微软出品，比 Ocelot 更现代）。

1
2
3
4
5
6
7
8


// Gateway/Program.cs
var builder = WebApplication.CreateBuilder();
builder.Services.AddReverseProxy()
 .LoadFromConfig(builder.Configuration.GetSection("ReverseProxy")); // 路由放配置

var app = builder.Build();
app.MapReverseProxy(); // 网关入口
app.Run();

 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


// Gateway/appsettings.json —— 路由配置
{
 "ReverseProxy": {
 "Routes": {
 "order-route": {
 "ClusterId": "order-cluster",
 "Match": { "Path": "/api/orders/{**catch-all}" }
 },
 "inventory-route": {
 "ClusterId": "inventory-cluster",
 "Match": { "Path": "/api/inventory/{**catch-all}" }
 }
 },
 "Clusters": {
 "order-cluster": {
 "Destinations": {
 "d1": { "Address": "http://order-service:8080/" }
 }
 },
 "inventory-cluster": {
 "Destinations": {
 "d1": { "Address": "http://inventory-service:8080/" }
 }
 }
 }
 }
}

1
2
3
4
5
6


网关集中处理（不在每个服务里重复）：
 - 路由（/api/orders → 订单服务）
 - 鉴权（统一验 token）
 - 限流、熔断
 - 协议转换
 生产环境再配多实例 + 负载均衡，保证网关本身高可用。

五、健康检查：编排的基础

K8s 和负载均衡器靠健康检查决定"流量往哪打"（第四篇分布式税）。ASP.NET Core 内置 HealthCheck。

 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


// 自定义健康检查：探测下游依赖
public class InventoryHealthCheck : IHealthCheck
{
 private readonly IInventoryClient _client;
 public InventoryHealthCheck(IInventoryClient client) => _client = client;

 public async Task<HealthCheckResult> CheckHealthAsync(
 HealthCheckContext context, CancellationToken ct = default)
 {
 try
 {
 var ok = await _client.PingAsync(ct);
 return ok ? HealthCheckResult.Healthy("inventory reachable")
 : HealthCheckResult.Degraded("inventory slow");
 }
 catch
 {
 return HealthCheckResult.Unhealthy("inventory down");
 }
 }
}

// 注册
builder.Services.AddHealthChecks()
 .AddCheck<InventoryHealthCheck>("inventory", failureStatus: HealthStatus.Unhealthy);

// 分别暴露存活探针 / 就绪探针（K8s 标准用法）
app.MapHealthChecks("/health/live", new() { Predicate = _ => false }); // 进程活着
app.MapHealthChecks("/health/ready", new() { Predicate = r => r.Tags.Contains("ready") });

1
2
3
4
5


K8s 里：
 livenessProbe → /health/live （进程活着吗）
 readinessProbe → /health/ready （依赖就绪、能接流量吗）
 就绪探针失败 → K8s 把该实例摘出流量，但不重启；
 存活探针失败 → K8s 重启容器。

六、弹性：Polly 应对分布式税

跨网络调用必加弹性（第四篇的超时/重试/熔断）。.NET 用 Polly，配合 HttpClientFactory。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// 订单服务调用库存服务，加满弹性策略
builder.Services.AddHttpClient<IInventoryClient, InventoryClient>(client =>
{
 client.BaseAddress = new("http://inventory-service:8080/");
 client.Timeout = TimeSpan.FromSeconds(3); // ① 超时
})
.AddTransientHttpErrorPolicy(p => // ② 重试（仅对临时错误）
 p.WaitAndRetryAsync(3, i => TimeSpan.FromMilliseconds(200 * Math.Pow(2, i))))
.AddTransientHttpErrorPolicy(p => // ③ 熔断
 p.CircuitBreakerAsync(5, TimeSpan.FromSeconds(30)));
// AddTransientHttpErrorPolicy 默认对 5xx、408、网络错误生效

1
2
3
4
5


这几行代码对应第四篇的整笔账：
 超时 → 别傻等慢服务
 重试 → 应对网络抖动（配合幂等，库存扣减接口必须幂等）
 熔断 → 库存服务挂了，订单服务直接快速失败，不耗尽自己的线程池
 → 切断雪崩的放大效应

七、可观测性：OpenTelemetry 串联

第七篇的链路追踪，几行代码接入。

1
2
3
4
5
6
7
8
9


// 各服务统一接入 OpenTelemetry
builder.Services.AddOpenTelemetry()
 .WithTracing(tp => tp
 .AddAspNetCoreInstrumentation() // 自动追踪 HTTP 入站
 .AddHttpClientInstrumentation() // 自动追踪 HttpClient 出站
 .AddSqlClientInstrumentation() // 自动追踪 DB 调用
 .AddOtlpExporter()); // 导出到 OTel Collector

builder.Logging.AddOpenTelemetry(); // 日志自动带 traceId

1
2
3
4
5


效果：一次"下单"请求
 网关(span) → 订单服务(span) → 库存服务(span) → DB(span)
 自动连成一条完整 trace，traceId 自动透传、日志自动关联。
 Jaeger 里一眼看到哪一段慢。
 → 这就是第七篇说的"微服务神经系统"，接入成本极低。

八、配置与外部化

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


每个服务的配置分环境（开发/测试/生产）外置：
 appsettings.json —— 默认值
 appsettings.Production —— 生产覆盖
 环境变量 / K8s ConfigMap / Secret —— 敏感和环境相关

 builder.Configuration
 .AddJsonFile("appsettings.json")
 .AddJsonFile($"appsettings.{env}.json", optional: true)
 .AddEnvironmentVariables(); // 环境变量优先级最高，适合容器

 分布式税里的"配置中心"（Nacos/Apollo）在规模上来后再引入，
 小系统先用环境变量 + ConfigMap 足够。

九、把前七篇串起来

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


这个骨架里，每一处都对应前面某一篇：

 工程结构、依赖方向 ← 第三篇：按领域切，单向依赖
 DI 注入一切 ← 可测试性（ASP.NET Core 笔记四）
 YARP 网关 ← 第六篇：统一入口、路由、鉴权
 健康检查 ← 第四篇：编排基础（K8s 探针）
 Polly 超时/重试/熔断 ← 第四篇：弹性，防雪崩
 OpenTelemetry ← 第七篇：可观测性神经系统
 服务间 HTTP + 幂等 ← 第五、六篇：一致性 + 通信
 配置外置 ← 第四篇：分布式税中的配置

 这就是一个"承重墙齐全"的微服务起点。
 业务往上长，基础设施已就位。

十、回到第一篇：要不要这么做

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


最后，回到系列第一篇的"权衡"：

 这个骨架是"当你要做微服务时"的标准起手式。
 但你要不要做微服务，回到那几个问题：

 - 团队是不是大到需要拆分协作？
 - 是不是有独立扩容 / 独立发布 / 故障隔离的真实需求？
 - 有没有 K8s + CI/CD + 可观测性的运维能力？

 如果没有 → 第二篇的"模块化单体"才是你的答案。
 把这套骨架的"DI + 分层 + 健康检查 + 可观测性"
 用在单体内部，一样成立，还省了网络和分布式税。

 记住：技术选型服务于问题和约束，不是反过来。

十一、系列小结

八篇下来，一条主线：

（一）架构是权衡：没有银弹，一切看约束
（二）单体被低估：模块化单体是大多数团队的起点
（三）拆分看领域：按业务切，不按技术层切
（四）分布式要收税：网络、一致性、可观测、运维，样样要自建
（五）一致性靠模式：核心收敛强一致，周边用最终一致 + Saga + Outbox
（六）通信看同步异步：REST/gRPC 与消息队列各擅其场
（七）可观测性是神经：日志 + 指标 + 链路，traceId 串联
（八）落地 ASP.NET Core：把理论变成可跑的代码

架构没有终点。系统会演进，约束会变化，今天的最优解是明天的技术债。保持权衡的思维、演进的视角、记录决策的习惯——这才是这套系列想留给你的，比任何具体技术都重要的东西。

后端架构实战（七）：可观测性——微服务的神经系统

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

写在前面

单体里排查问题，打开一个日志文件翻一翻就行。微服务里，一个用户请求要穿越 5 个服务，出问题了你去哪翻日志？哪个服务慢？

可观测性（Observability） 就是微服务的神经系统——没有它，系统就是个黑盒，只能靠玄学排查。这一篇讲清三大支柱：日志、指标、链路追踪。

这篇和我写的《.NET Dump 诊断》《.NET 性能优化与 Profiling》呼应——那两篇是"单进程深度诊断"，这篇是"跨服务的全局可观测"。

一、监控 vs 可观测性

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


监控（Monitoring）：你知道要问什么，系统告诉你答案
 → 预设告警、仪表盘（CPU 高了？错误率涨了？）
 → 应对"已知的未知"

可观测性（Observability）：你不一定知道要问什么，
 但系统能让你探索出答案
 → 任意维度下钻、关联日志/指标/链路
 → 应对"未知的未知"

 微服务复杂度高，新问题层出不穷，
 单靠预设监控不够，必须建可观测性。

二、三大支柱

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


┌──────────────────────────────────────────────────┐
│ 可观测性三大支柱 │
│ │
│ 1. 日志 Logs —— 离散的事件记录 │
│ "14:03 用户 123 下单失败，余额不足" │
│ │
│ 2. 指标 Metrics —— 聚合的数值（时间序列） │
│ "过去 1 分钟订单服务 QPS=1200, p99=85ms" │
│ │
│ 3. 链路 Traces —— 一个请求跨服务的完整轨迹 │
│ "请求 → 网关 → 订单 → 库存(慢) → 账户" │
│ │
│ 用 traceId 把三者串起来 = 完整的可观测性 │
└──────────────────────────────────────────────────┘

三、日志（Logs）

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


日志是离散的事件，记录"发生了什么"。

 好日志的特征：
 - 带上下文（谁、做了什么、结果）
 - 结构化（JSON，方便检索聚合，别只写纯文本）
 - 分级别（DEBUG/INFO/WARN/ERROR）
 - 带关联 ID（traceId，见第五节）

 反例：
 log("error") ← 完全没用，错什么了？
 log("user error: " + e) ← 没有上下文，哪个用户？

 好例：
 log.error({ userId: 123, orderId: 456, traceId }, "下单失败：余额不足")

 微服务：日志分散在各服务，必须聚合到统一存储
 ELK（Elasticsearch + Logstash + Kibana）/ Loki / Grafana

四、指标（Metrics）

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


指标是聚合的数值，回答"系统整体怎么样"。

 四大黄金信号（Google SRE）：
 1. 延迟（Latency） —— p50/p99 响应时间
 2. 流量（Traffic） —— QPS / 请求数
 3. 错误（Errors） —— 错误率 / 5xx 比例
 4. 饱和度（Saturation）—— CPU / 内存 / 连接数 / 队列堆积

 特点：
 - 聚合（不是每条请求一条，是按时间窗口聚合）
 - 低成本（存的是数字，不是文本）
 - 适合告警（阈值触发）

 指标 vs 日志的分工：
 指标 → 知道"出问题了 / 在哪里"（大盘、告警）
 日志 → 知道"具体怎么回事"（下钻查具体那条）

 常见：Prometheus（采集存储）+ Grafana（可视化）
 .NET 自带 metrics API，可导出到 Prometheus。

1
2
3
4
5
6


为什么用 p99 不用平均：
 100 个请求，99 个 10ms，1 个 10s
 平均 = 110ms（看着还行）
 p99 = 10s（真相：有 1% 的用户体验极差）

 平均会掩盖长尾。线上要看分位数（p95/p99）。

五、链路追踪（Traces）—— 微服务最重要的支柱

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


链路追踪：把一个请求经过的所有服务、每段的耗时，画成一条完整轨迹。

 一个 trace = 一个请求的完整旅程
 一个 span = 旅程中的一段（一次服务调用 / 一次 DB 查询）

 示例 trace：
 [下单请求] 总 120ms
 ├─ 网关 2ms
 ├─ 订单服务.createOrder 118ms
 │ ├─ 库存服务.deduct 10ms
 │ ├─ DB.insert_order 5ms
 │ └─ 账户服务.debit 100ms ← 慢点在这！
 └─ 响应 0ms

 一眼看出：账户服务是瓶颈。
 没有链路追踪，这种问题在微服务里几乎无从查起。

5.1 traceId 怎么传

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


关键机制：traceId 跨服务透传

 网关生成 traceId → 放进 HTTP Header（W3C Trace Context: traceparent）
 → 每个服务收到请求，从 Header 取出 traceId
 → 调下游时再把 traceId 透传出去
 → 日志里都打上这个 traceId

 效果：一条请求在所有服务、所有日志、所有指标里，共享一个 traceId。
 排查时按 traceId 一过滤，整条链路的来龙去脉全出来。

 标准协议：W3C Trace Context（traceparent / tracestate）
 几乎所有语言/框架都支持。

六、OpenTelemetry：统一的采集标准

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


痛点：以前日志用 A 厂商 SDK，指标用 B 厂商，链路用 C 厂商
 → 换一套后端就要改一堆代码，被厂商绑架

OpenTelemetry（OTel）：CNCF 的统一可观测性标准

 - 一套 API/SDK，同时采集 日志 + 指标 + 链路
 - 厂商无关：采集和后端解耦
 换后端（Jaeger/Prometheus/Tempo/Datadog…）只改配置，不改代码
 - 自动埋点：HTTP、DB driver、K8s 等自动注入 trace
 - 已是事实标准，主流语言都支持（含 .NET）

 .NET 接入：
 OpenTelemetry.Extensions.Hosting
 + 各 Instrumentation 包（AspNetCore / HttpClient / SqlClient）
 → 几行代码，自动给所有 HTTP 调用和 DB 查询加上 span

1
2
3
4
5
6
7
8


典型架构：

 应用（OTel SDK）─采集─→ OTel Collector ─路由─→ 后端
 ├─ Jaeger/Tempo（链路）
 ├─ Prometheus（指标）
 └─ Loki/ES（日志）

 Collector 是中间层：接收、处理、转发，解耦应用和后端。

七、告警：可观测性的出口

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


采集了一堆数据，最终要变成"主动通知"——告警。

 好告警的原则：
 1. 基于症状，不是原因
 告"下单错误率 > 1%"（用户真受影响），别告"CPU 80%"（可能没事）
 2. 可执行
 每条告警都该有对应的处理动作；收到的告警没人知道怎么处理 = 噪音
 3. 少而精
 告警风暴会让所有人麻木；宁可少，要准
 4. 分级
 P0 电话叫醒 / P1 工作时间处理 / P2 记录即可

 常见反模式：告 CPU/内存/磁盘每一个阈值 → 天天报警，全员麻木。

八、可观测性的落地优先级

1
2
3
4
5
6
7
8
9


从零搭建，按这个顺序：

 1. 结构化日志 + 日志聚合（先有日志能查）
 2. 基础指标 + 黄金信号仪表盘（知道整体健康度）
 3. 关键链路追踪（核心请求的 traceId 透传）
 4. 统一用 OpenTelemetry 重新规范（前面用临时方案也不要紧）
 5. 基于症状的告警

 不要一上来追求全套，先把"出问题能查"建起来。

九、小结

可观测性 > 监控：应对"未知的未知"，能探索而不只是预设告警
三大支柱：日志（离散事件）、指标（聚合数值）、链路（请求轨迹），用 traceId 串联
指标看分位数（p99）不看平均，平均会掩盖长尾
链路追踪是微服务最重要的支柱：trace + span，traceId 跨服务透传
OpenTelemetry：统一采集标准，厂商无关，已成事实标准
告警：基于症状、可执行、少而精、分级
落地顺序：日志聚合 → 基础指标 → 链路追踪 → OTel 规范化 → 告警

最后一篇，把前七篇的理论落到 ASP.NET Core 代码，搭一个微服务骨架。

后端架构实战（六）：服务间通信——RPC、REST 还是消息

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

写在前面

上一篇解决了"跨服务数据怎么一致"，这一篇解决"跨服务怎么对话"。

服务间通信是个看似简单、实则踩坑最密集的话题。选错通信方式，会带来延迟、耦合、故障放大一连串问题。核心决策只有一个：同步，还是异步？

这篇会和我的中间件笔记呼应：《消息队列》系列讲了 RabbitMQ/Kafka 本身，《Nginx》系列讲了反向代理和负载均衡。这里讲的是"在架构层怎么选"。

一、同步 vs 异步：第一性抉择

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


同步通信（打电话）：
 调用方发请求 → 等 → 拿到响应
 ✓ 直观、顺序清晰、易理解
 ✓ 能立即知道结果（成功/失败）
 ✗ 调用方被阻塞，吞吐受限
 ✗ 强耦合：被调方挂了，调用方也受影响
 ✗ 故障会沿调用链同步放大

异步通信（发邮件）：
 调用方发消息 → 立即返回 → 被调方按自己节奏处理
 ✓ 解耦、高吞吐、削峰填谷
 ✓ 调用方不等被调方，故障不直接传导
 ✗ 不立即知道结果（要回调/查询）
 ✗ 一致性弱化（最终一致）
 ✗ 调试、追踪更复杂

1
2
3
4
5
6


选择原则：
 必须立即拿到结果 → 同步（查余额、读商品、用户登录）
 结果可以晚点、且能解耦 → 异步（发通知、记日志、算积分）

 反模式：把所有通信都做成同步
 → 一次请求串行调 5 个服务，延迟叠加、雪崩放大。

二、同步通信：REST vs RPC

2.1 REST

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


基于 HTTP，面向"资源"
 GET /orders/123 查
 POST /orders 建
 PUT /orders/123 改
 DELETE /orders/123 删

 ✓ 通用、标准化、人可读
 ✓ 跨语言、跨平台、防火墙友好
 ✓ 生态丰富（网关、监控、文档 Swagger）
 ✗ 基于文本（JSON），序列化开销大
 ✗ 语义偏向 CRUD，复杂业务动作要绕（POST /orders/123/cancel）
 ✗ 没有强类型契约（靠 OpenAPI 补）

 适合：对外 API、和前端/第三方对接、绝大多数业务场景

2.2 RPC（gRPC 为代表）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


基于 HTTP/2 + Protobuf，面向"动作/方法"
 stub.CancelOrder(request) → response

 ✓ 二进制传输，体积小、速度快（比 JSON 快数倍）
 ✓ 强类型契约（.proto 生成各语言客户端）
 ✓ 支持 HTTP/2 多路复用、流式（stream）
 ✗ 不可读（二进制），调试要工具
 ✗ 浏览器/前端不友好（要 gRPC-Web 网关）
 ✗ 强耦合：proto 一变客户端要重新生成

 适合：内部服务间高频调用、低延迟、大数据量、流式场景

1
2
3
4
5
6


选型经验：
 对外、前端、第三方 → REST
 内部服务间、低延迟、高吞吐 → gRPC
 大多数团队 → REST 打天下，内部热点链路再换 gRPC

 不要一上来全 gRPC，proto 的耦合成本会被低估。

三、异步通信：消息队列

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


通过 Broker（消息中间件）解耦

 生产者 → 消息队列 → 消费者
 生产者不用知道谁消费、有几个、在哪

 ✓ 解耦（生产者消费者互不感知）
 ✓ 削峰（流量高峰积压在队列，消费者按能力处理）
 ✓ 异步、高吞吐
 ✓ 故障隔离（消费者挂了，消息留在队列）
 ✗ 一致性弱（最终一致）
 ✗ 增加架构复杂度（Broker 本身要高可用）

3.1 两大流派

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


RabbitMQ —— 传统消息队列（AMQP）
 特点：丰富的路由（Exchange/Queue/Binding）、可靠投递、消息确认
 模型：一条消息被消费后删除
 强项：业务消息路由、可靠投递、延迟队列
 弱项：吞吐和堆积能力一般

Kafka —— 分布式日志/流平台
 特点：高吞吐、可堆积海量消息、分区有序、支持流处理
 模型：消息是"日志"，可重复消费、按 offset
 强项：日志、事件溯源、大数据管道、超高吞吐
 弱项：路由能力弱、不适合复杂业务路由

 详细对比见《消息队列（四）：RabbitMQ vs Kafka 深度对比》。

3.2 两种消息语义

1
2
3
4
5
6
7
8


点对点（Queue）：一条消息被一个消费者消费
 → 任务分发（一个订单只被一个处理者处理）

发布订阅（Topic）：一条消息被所有订阅者消费
 → 事件广播（订单创建后，积分、通知、统计都各收一份）

 事件驱动架构（EDA）主要用 Pub/Sub：
 订单服务发"订单已创建"，所有感兴趣的下游各自订阅。

四、消息可靠性的三个保证

用消息队列，必须想清楚这三件事，否则会丢消息：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


1. 生产端不丢：确认机制 + 重试 + 本地落库
 → 关键消息用 Outbox 模式（上一篇讲过）

2. Broker 不丢：持久化 + 副本 + 确认
 → 消息持久化磁盘、集群多副本、生产者等 broker 确认

3. 消费端不丢：手动确认 + 幂等
 → 处理成功后再 ack（别自动 ack）
 → 处理失败重试，重试要幂等（消息会重复投递）

 三个环节任何一个漏了，消息就会丢。

五、服务间通信的反模式

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


反模式 1：同步链路过长
 A→B→C→D→E，五个服务串行同步调用
 → 延迟叠加、任意一环故障全链路崩
 → 能异步化的副作用（日志、通知、统计）坚决异步

反模式 2：循环依赖
 A 调 B，B 又调 A
 → 死锁可能、边界划分反了（回到第三篇：拆错了）

反模式 3：共享数据库当通信
 两个服务通过读写同一张表"传话"
 → 表结构耦合，等于没拆，且并发冲突
 → 服务通信要走 API/消息，不偷懒走数据库

反模式 4：消息不带版本
 事件 schema 一改，所有消费者崩
 → 事件契约要版本化、向后兼容

反模式 5：忽略超时和熔断
 同步调用不设超时 → 一个慢服务拖垮调用方线程池
 → 永远设超时 + 熔断（第四篇的分布式税）

六、网关：通信的统一入口

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


对外不用让客户端直连每个服务，前面加一层 API 网关：

 客户端 → API 网关 → 各微服务

 网关职责：
 - 统一鉴权（token 校验集中在一处）
 - 限流、熔断
 - 路由（外部 REST 路由到内部 gRPC）
 - 协议转换（gRPC-Web、聚合多个服务）
 - 灰度、A/B

 常见：Kong / APISIX / Nginx（见我的 Nginx 系列）/ Ocelot（.NET）/ YARP（.NET）

 注意：网关是单点，必须高可用（多实例 + 负载均衡）。

七、一份选型速查

1
2
3
4
5
6
7
8
9


需求 选择
──────────────────────────────────────────────
对外 API / 前端调用 REST
内部高频、低延迟调用 gRPC
必须立即拿结果 同步（REST/gRPC）
可解耦、可削峰、能异步 消息队列
事件广播、多下游订阅 Kafka / RabbitMQ Pub-Sub
可靠事件投递 Outbox + 消息队列
统一入口、鉴权、限流 API 网关

八、小结

第一性抉择：同步（要立即结果）还是异步（可解耦、能晚点）
同步：REST（通用、对外）vs gRPC（内部、低延迟、强类型）
异步：消息队列解耦、削峰、故障隔离；RabbitMQ 重路由，Kafka 重吞吐/流
可靠性三保证：生产端确认+Outbox、Broker 持久化+副本、消费端手动ack+幂等
五大反模式：同步链路过长、循环依赖、共享库通信、消息不版本化、忽略超时熔断
网关：统一入口，集中鉴权/限流/路由，必须高可用

下一篇讲把这些服务监控起来——可观测性，微服务的神经系统。

后端架构实战（五）：分布式数据一致性——ACID 之后怎么办

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

写在前面

上一篇把"分布式税"列了一遍，其中最重的一笔是数据一致性。这一篇就把它讲透。

单体的世界里，一个数据库事务就能保证 ACID，干净利落。一旦拆成微服务、每个服务一个库，跨库就再也没有 ACID 了。那数据一致性怎么保证？答案是：放弃强一致，用一系列模式把"最终一致"工程化。

前置：这篇假设你理解 ACID 和隔离级别。我在《数据库系列（四）：事务与 ACID》《数据库系列（五）：MVCC 与隔离级别》里讲过单机版。

一、问题：跨服务的"事务"怎么办

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


经典场景：下单 = 创建订单 + 扣库存 + 扣余额 + 加积分

单体：一个数据库事务
 BEGIN;
 insert 订单; update 库存; update 余额; insert 积分;
 COMMIT;
 → 要么全成功，要么全回滚。ACID 保护你。

微服务：订单/库存/账户/积分 各自独立的库
 insert 订单 ✅ → 扣库存 ✅ → 扣余额 ❌（账户服务挂了）
 → 订单建了、库存扣了、余额没扣。钱少货没了。灾难。

 跨库没有 ACID，怎么办？

二、两条根本出路

1
2
3
4
5
6
7
8


出路 A：把强一致收敛在一个服务内（首选）
 → 核心数据合并到同一个库（甚至同一个服务）
 → 第三篇说过：核心交易该收敛在一个上下文里
 → 能不分布式，就不分布式

出路 B：接受最终一致，用模式工程化（本篇重点）
 → 实在拆开了，就放弃 ACID，保证"最终"一致
 → 下面四个模式：Saga / 事件驱动 / Outbox / CQRS

第一选择永远是 A。B 是"不得不拆"时的补救。不要为了用 Saga 而 Saga。

三、Saga 模式

Saga：把一个分布式事务拆成一串本地事务，每个本地事务有对应的补偿动作。任何一步失败，就反向执行已完成步骤的补偿，最终达到"一致"。

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


下单 Saga（每步都有补偿）：

 正向： 补偿（失败时反向执行）：
 1. 创建订单 → 取消订单
 2. 扣库存 → 还库存
 3. 扣余额 → 退余额
 4. 加积分 → 扣积分

 执行：
 1 ✅ → 2 ✅ → 3 ❌（余额不足）
 → 触发补偿：还库存(2) → 取消订单(1)
 → 最终：订单取消、库存还原、余额没动。一致。

Saga 有两种协调方式：

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


编排（Orchestration）—— 有一个中心协调者
 Orchestrator 按顺序调用各服务，跟踪状态，失败时发补偿命令
 ✓ 流程清晰、易监控、状态可控
 ✗ 协调者成了单点（需高可用）
 适合：流程复杂、步骤多的核心业务（如下单全流程）

协同（Choreography）—— 无中心，事件驱动
 每个服务订阅事件，完成自己的事后发新事件
 订单服务发"订单已创建" → 库存服务听到后扣库存并发"库存已扣" → ...
 ✓ 去中心化、易扩展、无单点
 ✗ 流程隐式、难追踪（出问题不知道现在走到哪）
 适合：流程简单、步骤少

Saga 的底子是分布式事务理论，我在《分布式系统学习笔记（四）：分布式事务》里讲过 2PC/TCC/Saga 的对比，这里只讲架构落地。

Saga 的两个硬骨头

1
2
3
4
5
6
7


1. 补偿必须幂等
 补偿动作可能被重试执行（网络抖动）
 → "扣库存"的补偿"还库存"必须能重复执行不出错

2. 不是所有操作都能补偿
 "发短信""扣款给第三方"这类副作用无法撤销
 → 把不可补偿的步骤放到最后，或用"预占/确认"两阶段

四、事件驱动 + 最终一致性

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


核心理念：服务之间通过"事件"解耦，不强求同步一致

 订单服务：创建订单后，发"订单已创建"事件（不关心谁消费）
 → 库存、积分、通知 各自订阅，异步处理
 → 订单服务不等待它们，立即返回成功

 一致性保证：弱化了
 订单成功了，但积分可能晚几秒才加（最终一致）
 需要业务接受这个延迟窗口

 收益：解耦、异步、高可用、可扩展

最终一致性的前提：业务能容忍短暂不一致。账号余额晚 3 秒更新，用户感知不到；但支付晚 3 秒就不行。核心资金强一致，周边副作用最终一致——这是通用法则。

五、Outbox 模式：解决"事件发了但没发出去"

事件驱动有个经典坑：业务操作和发事件不在一个事务里。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


问题：
 update 订单 ✅（提交了）
 发"订单已创建"事件 ❌（发消息时网络挂了）
 → 订单建了，但下游永远收不到事件。

 或者反过来：
 发事件 ✅ → 写库 ❌
 → 下游收到事件，但订单其实没建。

 根因：数据库事务和消息中间件是两个系统，没法一起 ACID。

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


Outbox 模式（发件箱）：

 把"事件"当成一行记录，和业务数据写进同一个库：

 BEGIN;
 insert 订单;
 insert into outbox(event) values('订单已创建'); -- 同库同事务
 COMMIT;
 → 订单和事件要么都成功，要么都失败。ACID 保护。

 然后一个独立进程（或 CDC 工具）：
 轮询 outbox 表 → 把事件投递到消息队列 → 标记已发送
 常见：Debezium（监听 binlog）、自研轮询 worker

 效果：业务操作和事件发布，获得"原子性"。
 这是事件驱动架构的标准配置。

六、幂等性：分布式一致性的基石

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


为什么必须幂等：
 网络会重试、消息会重复投递、补偿会重复执行
 → 同一个操作可能被执行多次
 → 必须保证"执行一次 = 执行多次"的结果相同

 实现手段：
 1. 唯一业务 ID + 去重表（处理过就跳过）
 2. 状态机（只有特定状态才能流转）
 3. 乐观锁版本号（update ... where version = x）
 4. 数据库唯一约束（重复插入直接失败）

 经验：所有跨服务、跨网络的写操作，默认就要按幂等设计。

七、CQRS：读写分离

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


CQRS（Command Query Responsibility Segregation）

 传统：一个模型既读又写
 CQRS：写模型（命令）和读模型（查询）分开

 写模型：面向业务一致性，规范化存储（如关系库）
 读模型：面向查询性能，反规范化（如 ES、Redis、物化视图）

 数据流：
 写 → 写库 → 发事件 → 同步到读库（最终一致）
 读 → 直接读读库（快、可定制）

 价值：
 ✓ 读写各自优化（写要一致，读要快）
 ✓ 读侧可水平扩展、多形态查询
 ✓ 天然配合事件驱动

 代价：
 ✗ 复杂度上升（要维护数据同步）
 ✗ 读写有延迟（最终一致）

 适用：读多写少、查询复杂、读写负载差异大的场景。
 不要在简单 CRUD 上用 CQRS。

八、一份选型清单

1
2
3
4
5
6
7
8
9


场景 推荐方案
──────────────────────────────────────────────────────
核心交易（下单、支付、扣款） 强一致，尽量收敛在一个服务/库
跨服务流程，步骤多，需补偿 Saga（编排式）
跨服务流程，步骤少，去中心 事件驱动（协同式）
副作用通知（积分、通知、统计） 事件驱动 + 最终一致
事件可靠投递 Outbox 模式
读多写少、查询复杂 CQRS
所有跨网络写操作 必须幂等

九、小结

第一原则：核心数据尽量收敛在一个库/服务，能不分布式就不分布式
Saga：本地事务链 + 补偿；编排式（中心）适合复杂流程，协同式（事件）适合简单流程
事件驱动：服务间通过事件解耦，接受最终一致
Outbox 模式：把事件写入业务库同事务，解决"事件丢失"
幂等性：所有跨网络写操作的基石
CQRS：读写分离，读侧可极致优化，代价是复杂度和延迟
通用法则：核心资金强一致，周边副作用最终一致

下一篇讲服务之间怎么通信：同步的 RPC/REST，还是异步的消息？

后端架构实战（四）：微服务的"分布式税"——你准备好买单了吗

Sun, 31 May 2026 10:00:00 +0800

写在前面

前三篇我一直在"劝退"过早微服务化，不是反对微服务，是想让你想清楚再拆。这一篇就把账算明白：拆成微服务之后，你到底要为哪些隐性成本买单。

我把这些成本叫做**“分布式税”**——单体里免费的东西，到了分布式环境，每一项都要你自己花人、花钱、花时间重新建起来。

一、什么叫"分布式税"

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


单体里（进程内）免费的能力：

 - 函数调用 = 直接 new、直接调，纳秒级
 - 强一致性 = 一个数据库事务搞定
 - 配置 = 读本地配置文件
 - 日志 = 写同一个文件
 - 鉴权 = 一个进程内的中间件
 - 故障传播 = 进程挂了，全挂（简单粗暴）

微服务里（跨网络）每一项都要重新建：

 - 函数调用 → 网络调用（毫秒级、会超时、会丢包）
 - 强一致 → 分布式事务（Saga / TCC / 最终一致）
 - 配置 → 配置中心（集中下发、动态刷新）
 - 日志 → 日志聚合（收集到统一存储）
 - 鉴权 → 每个服务都要验 token
 - 故障 → 一个挂了，可能雪崩倒一片

 这些"重建"，就是分布式税。

二、第一笔税：网络根本不可靠

这是分布式系统一切痛苦的根源。

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


进程内调用 vs 网络调用：

 进程内调用：
 ✓ 几乎不会失败（除非进程崩）
 ✓ 纳秒~微秒级
 ✓ 没有序列化开销

 网络调用：
 ✗ 会超时（对方慢、网络抖动）
 ✗ 会丢包、会重试、会乱序
 ✗ 毫秒级起步，还要序列化
 ✗ "超时"最可怕——不知道对方到底执行了没有

 八大谬误（Peter Deutsch）：
 1. 网络是可靠的 ❌
 2. 延迟为零 ❌
 3. 带宽是无限的 ❌
 4. 网络是安全的 ❌
 5. 拓扑不会变化 ❌
 6. 只有一个管理员 ❌
 7. 传输成本为零 ❌
 8. 网络是同构的 ❌

代价：每一次跨服务调用，都要处理重试、超时、幂等、降级。单体里一个 try-catch 搞定的，微服务里是一整套弹性策略。

网络为什么不可靠、CAP 为什么成立——我在《分布式系统学习笔记（一）：CAP 与一致性》里讲过底子。这里只说工程后果。

三、第二笔税：服务发现与配置

单体里，所有代码在一个进程，互相调函数即可。微服务里，“找谁"和"用什么配置"成了问题。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


单体：函数地址 = 编译期固定
微服务：服务实例的 IP/端口是动态的（容器漂移、弹性扩缩）

 必须自建的能力：
 - 服务注册与发现（谁在线、在哪）
 常见：Consul / Nacos / etcd / K8s Service / Eureka
 - 配置中心（配置不再散落各服务）
 常见：Nacos / Apollo / Consul KV / K8s ConfigMap
 - 动态刷新（改配置不重启）

 这些都是单体里"不存在"的基础设施。

四、第三笔税：数据一致性

这是最重的一笔税，下一篇会专门展开，这里先列账：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


单体：一个事务保证 ACID
微服务：每个服务一个库，跨库没有 ACID

 你必须自建：
 - 分布式事务方案（Saga、TCC、Outbox 模式）
 - 最终一致性补偿机制
 - 幂等性保证（重试导致的重复执行）
 - 对账机制（数据不一致时的人工/自动核对）

 详见我写的《分布式系统学习笔记（四）：分布式事务》。
 本系列第五篇会讲它怎么在数据架构上落地。

五、第四笔税：可观测性

单体里，一个请求的处理在一个进程内，看一个日志文件就懂了。微服务里，一个请求要经过 5 个服务，出问题你怎么定位？

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


必须自建"微服务的神经系统"：

 - 链路追踪（Trace）
 给每个请求一个 traceId，跨服务透传
 常见：OpenTelemetry / Jaeger / Zipkin / SkyWalking

 - 指标监控（Metrics）
 每个服务的 QPS、延迟、错误率
 常见：Prometheus + Grafana

 - 日志聚合（Logs）
 所有服务的日志收到一处，按 traceId 串联
 常见：ELK / Loki

 没有这三件套，微服务一旦出问题 = 黑盒，只能玄学排查。
 第七篇会专门讲可观测性。

六、第五笔税：可靠性与弹性

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


单体里：一个函数失败 → 抛异常，调用方决定怎么办
微服务里：一个服务失败 → 故障会沿调用链放大，可能雪崩

 必须自建：
 - 超时（Timeout）—— 别傻等
 - 重试（Retry）—— 配合幂等
 - 熔断（Circuit Breaker）—— 别打已经挂的服务
 - 限流（Rate Limit）—— 别被流量压垮
 - 降级（Fallback）—— 给个兜底响应
 - 舱壁隔离（Bulkhead）—— 别让一个慢调用拖垮线程池

 .NET 生态：Polly（这套东西几乎成了标配）
 本系列第八篇落地时会用上。

1
2
3
4
5


雪崩示意：
 服务 A 依赖 B，B 依赖 C
 C 慢了 → B 的线程被占满 → B 也慢 → A 的线程被占满 → A 也挂
 一个底层小故障，逐层放大，拖垮整条链路。
 熔断 + 舱壁就是用来切断这种放大效应的。

七、第六笔税：运维与部署

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


单体运维：1 个应用 × N 台机器
微服务运维：M 个服务 × N 个实例 × 动态变化

 - 需要容器化（Docker）+ 编排（K8s）
 见我写的 Docker / K8s 系列
 - 需要 CI/CD（每个服务独立构建、独立发布）
 - 需要版本兼容（新老接口并存期）
 - 需要 API 网关（统一入口、鉴权、限流）
 - 需要 DevOps 能力（SRE 文化）

 团队没有这些能力，上微服务 = 上灾难。

八、账单汇总：值得吗

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


拆成微服务，你要新增的基础设施清单：

 □ 服务注册发现 □ 配置中心
 □ API 网关 □ 分布式事务/一致性
 □ 链路追踪 □ 指标监控
 □ 日志聚合 □ 熔断/限流/重试（Polly）
 □ 容器编排（K8s） □ CI/CD 流水线
 □ 幂等 + 对账 □ 版本兼容策略

 收益（只有规模到了才兑现）：
 ✓ 独立部署、独立扩容、技术栈解耦、故障隔离、团队解耦

 判断标准：
 规模/团队/解耦需求 带来的收益 > 上面这份税单 → 拆
 否则 → 老老实实模块化单体

 这就是第一篇说的"权衡"。

九、小结

分布式税：单体里免费的能力，微服务里每一项都要自建
网络不可靠是根源：每次跨服务调用都要处理超时/重试/幂等/降级
服务发现 + 配置中心：解决"找谁"和"用什么配置”
数据一致性是最重的税：Saga/最终一致/幂等/对账（下一篇详谈）
可观测性：链路追踪 + 指标 + 日志，否则微服务是黑盒
弹性：超时/重试/熔断/限流/降级/舱壁，防止雪崩
运维：K8s + CI/CD + 网关 + 版本兼容
决策：只有当解耦收益 > 这份税单，才值得拆

下一篇，把最重的一笔税——分布式数据一致性——彻底讲透。

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

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 限界上下文：业务子领域的自治范围，是天然的拆分单位
一概念多模型：每个上下文只保留自己需要的视图，不要追求全局统一模型
边界好坏的试金石：高频一起变更的，应在同一服务；出现密集跨服务调用/共享库/循环依赖，说明拆错了
粒度：一个小团队能独立负责为单位，先粗后细，别为扩容而拆

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

后端架构实战（二）：为单体正名——模块化单体才是被低估的最佳实践

Fri, 29 May 2026 10:00:00 +0800

写在前面

上一篇我说"架构是权衡"，不要跳级。这一篇就来论证：对绝大多数团队，单体是起点，甚至是很长一段时间内的终点。

但这里的"单体"不是那个被嘲笑的"大泥球"（Big Ball of Mud）。我要替它正名的是它的升级版——模块化单体（Modular Monolith）。它可能是你被低估得最厉害的一个选项。

一、单体到底做错了什么

先搞清楚：单体为什么名声这么差？

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


被骂的"单体"，其实是"没设计的单体"——大泥球：

 - 所有代码堆在一个工程里
 - 模块间任意互相调用（没有边界）
 - 数据库一张大表谁都能读写
 - 改一处怕牵连全身
 - 发布必须整体一起发

 这些问题，根因不是"单体"，是"没有边界"。
 把同样的代码拆成 20 个微服务，边界还是乱的，
 只是把"一个大泥球"变成了"20 个小泥球 + 网络"。

关键认知：单体 ≠ 混乱。单体也可以有清晰的模块边界。 混乱的是"没有边界"，不是"部署在一起"。

二、单体被低估的优势

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


单体（即使不模块化）天然拥有的好东西：

 ✓ 一个进程内调用，没有网络开销
 → 性能天花板高，调试简单

 ✓ 强一致性"免费"
 → 一个数据库事务搞定，不用 Saga、不用最终一致

 ✓ 部署简单
 → 一个二进制 / 一个镜像，没有编排地狱

 ✓ 开发体验好
 → 一个 IDE 打开全栈，重构随便改，编译器帮你查

 ✓ 监控简单
 → 一个进程的日志、指标，不用分布式追踪

 ✓ 没有"分布式税"
 → 不用服务发现、配置中心、链路追踪、熔断……

这些优势，一旦你拆成微服务，全部要花钱、花人、花时间自己补回来。第四篇我会专门算这笔账。

三、什么时候单体真的不够用

不替单体无脑洗白。它确实有扛不住的时候：

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


单体扛不住的信号（出现这些，才考虑拆）：

 1. 团队规模超过 8~10 人，互相踩脚
 → 多人改同一个工程，合并冲突、发布互相阻塞

 2. 局部需要独立扩容
 → 只有"秒杀"模块要 100 倍算力，整体扩太浪费

 3. 局部需要独立的技术栈 / 发布节奏
 → AI 推理要用 Python，核心交易用 .NET，没法塞一起

 4. 故障爆炸半径太大
 → 一个小 bug 拖垮整个进程，影响所有功能

 注意：上面任何一条单独出现，都不一定非要上微服务。
 先看能不能用"模块化单体 + 进程内隔离"解决。

四、模块化单体：鱼和熊掌兼得

模块化单体的核心思想：部署还是一个，但内部按模块严格切分边界。

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


┌─────────────────────────────────────────────┐
│ 单体应用（一个进程） │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 订单模块 │ │ 用户模块 │ │ 商品模块 │ │
│ │ Order │ │ User │ │ Product │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ │ 只通过模块的公开接口调用 │ │
│ └──────────┬──────────────┘ │
│ ┌───┴────┐ │
│ │ 共享内核 │ │
│ └────────┘ │
└─────────────────────────────────────────────┘

 规则：
 - 模块之间不直接 new 对方的内部类
 - 只调用对方 module 暴露的 Service / 接口
 - 理想情况下，每个模块有自己独立的表（Schema 隔离）

它保留了单体的全部优势（一个进程、强一致、好调试），又解决了"边界混乱"的根因。

4.1 怎么落地边界

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


1. 按业务能力划分模块（不是按技术分层）
 订单、用户、商品、支付…… 而不是 Controller/Service/Dao

2. 模块对外只暴露少量接口（公开 API）
 内部实现细节对其他模块不可见

3. 数据归属清晰
 订单表只有订单模块写，别人要数据走订单模块的接口
 （这条最难，也最关键——下一节展开）

4. 工程结构上做硬隔离
 - .NET：每个模块一个 Project，依赖方向单向
 - 用 InternalsVisibleTo / 架构测试（如 NetArchTest）强制约束
 - 谁违规了编译/测试就挂

4.2 为什么不直接拆成微服务

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


模块化单体 vs 微服务：

 模块化单体：先在进程内把边界画对
 - 边界画错了？重构成本 = 改代码（小时级）
 - 跑通了再决定要不要物理拆开

 直接上微服务：在网络上画边界
 - 边界画错了？重构成本 = 跨服务迁移数据和流量（周/月级）
 - 而且多了网络、一致性、运维一堆税

 结论：先用模块化单体验证边界，再考虑物理拆分。
 这是最稳的演进路径。

五、最容易踩的坑：共享数据库

模块化单体最大的诱惑，也是最大的坑——所有模块共用一个数据库，互相直接读写对方的表。

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


错误做法：
 订单模块为了"方便"，直接 JOIN 用户表、商品表
 → 表结构耦合，用户表一改，订单模块崩
 → 边界形同虚设，又退回大泥球

正确做法：
 - 每个模块"拥有"自己的表（schema 或表前缀划分）
 - 别的模块要数据，调模块的接口，不直接读表
 - 共享库可以，但读写权限按模块隔离

 这一步做不好，模块化就是假的。
 数据边界，才是真正的边界。

这正是下一篇的主题：服务/模块到底该按什么切。答案是按"数据和领域"切，不是按技术层切。

六、真实世界的成功案例

别以为单体是"落后"的代名词：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


- Stack Overflow：几个单体应用撑住全球 Top 50 的流量
 几百台服务器，没用微服务，靠的就是模块化 + 极致优化

- Shopify：早期巨型 Rails 单体，逐步模块化
 到很大规模才开始"模块化单体 → 组件化"演进

- Basecamp（37signals）：长期单体 + 模块化
 明确反对过早微服务化

 共同点：先榨干单体的价值，确认边界，再按需拆。
 没有一上来就微服务的。

七、小结

被骂的不是单体，是"没有边界的大泥球"
单体的天然优势：进程内调用、强一致免费、部署简单、好调试——拆了都要花钱补
拆分信号：团队踩脚、局部扩容、技术栈差异、爆炸半径——出现且模块化解决不了，才拆
模块化单体：部署还是一个，内部按业务模块严格切边界，鱼和熊掌兼得
边界关键在数据：每个模块拥有自己的表，禁止跨模块直接读写
演进路径：先用模块化单体验证边界，再考虑物理拆分——不要跳级

下一篇讲拆分的第一性原理：模块/服务到底按什么切——领域、数据，还是技术？

后端架构实战（一）：好架构的本质——没有银弹，只有权衡

Thu, 28 May 2026 10:00:00 +0800

写在前面

这是「后端架构实战」系列的第一篇。我写了不少 .NET、分布式、中间件、数据库的笔记，讲的都是"零件"。这个系列想聊的是另一件事：怎么把零件搭成一辆车——也就是软件架构。

但开篇我不想聊微服务、不聊 DDD、不聊任何具体风格。我想先回答一个更根本的问题：到底什么是"好架构"？

答案只有两个字：权衡。理解了这一点，后面七篇才有意义。

一、架构到底是什么

很多人对架构的印象是"画框图"——几张分层图、几个箭头、一堆方框。那是架构的产出，不是架构本身。

1
2
3
4
5
6
7
8
9


架构的本质：在约束下，做"职责如何分配"的决策

 - 哪些东西放在一起，哪些东西拆开
 - 哪些决策现在做，哪些决策推迟
 - 哪些东西自研，哪些东西用别人的
 - 哪些质量属性优先，哪些先牺牲

 画图只是把这些决策记录下来。
 没有决策依据的图，就是 PPT。

一个判断标准：如果你说不出"我为什么这么选、放弃了什么"，那你就没在做架构，只是在抄。

二、第一性原理：一切都是权衡

Fred Brooks 有句名言："没有银弹"（No Silver Bullet）——没有任何一种技术或方法能让软件工程的本质难题一夜消失。架构同理：

1
2
3
4
5
6
7
8


不存在"最好的架构"，只存在"在当前约束下最合适的架构"

 同一个系统，在不同团队、不同阶段、不同规模下，
 "好架构"的答案完全不同。

 10 人的电商团队和 1000 人的电商团队，
 "正确"的架构天差地别——
 不是谁对谁错，是约束变了。

所以资深架构师最常说的话不是"应该用 X"，而是 “It depends”（看情况）。这不是圆滑，是因为架构决策永远依赖上下文。

三、约束的四象限

“It depends” 到底 depend 什么？四个维度：

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


┌─────────────────────────────────────────────────────────┐
│ 1. 规模（Scale） │
│ 用户量、数据量、QPS、团队人数 │
│ → 决定要不要拆、要不要分布式 │
│ │
│ 2. 时间（Time） │
│ 上市压力、迭代节奏、技术债务容忍度 │
│ → 决定先糙快还是先打好地基 │
│ │
│ 3. 团队（Team） │
│ 人数、技能栈、分布式经验、运维能力 │
│ → 决定能 hold 住多复杂的架构 │
│ │
│ 4. 成本（Cost） │
│ 服务器、人力、第三方服务、维护开销 │
│ → 决定自研还是采购、能上多少中间件 │
└─────────────────────────────────────────────────────────┘

 四个维度互相牵制。规模涨了 → 团队要扩 → 成本要加 → 时间可能更紧。
 架构决策 = 在这四个约束的"可行域"里找最优解。

关键认知：约束是会变的。今天的最优解，半年后可能就是技术债。所以架构不是一次定死，而是要能演进（第七节会展开）。

四、几个经典的权衡

4.1 性能 vs 可维护性

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


追求极致性能 → 紧凑的代码、手工优化、绕过抽象
 ✓ 跑得快
 ✗ 晦涩难懂、改一处崩三处、新人接手难

追求可维护性 → 清晰的抽象、分层、命名
 ✓ 好改、好懂、好测
 ✗ 多一层调用、多一点开销

 绝大多数业务系统：优先可维护性（性能够用就行）
 少数热路径（交易撮合、广告竞价）：性能压倒一切

4.2 一致性 vs 可用性

这就是 CAP。分布式系统的所有痛苦都源于此：

1
2
3
4
5


要强一致 → 协调多数节点、锁、阻塞 → 牺牲可用性和性能
要高可用 → 允许暂时不一致 → 牺牲一致性，要处理冲突

 详见我写的《分布式系统学习笔记（一）：CAP 与一致性》。
 本系列第五篇会讲它在数据层怎么落地。

4.3 简单 vs 灵活（最容易踩的坑）

1
2
3
4
5
6
7
8
9


过度设计（Over-engineering）：
 为"将来可能要用"的需求，提前搭了一堆抽象层
 → 现在用不上，将来真要用时发现猜错了
 → 维护成本白白增加

 YAGNI 原则：You Aren't Gonna Need It。
 不要为想象中的需求买单。
 但也要留"可演进"的接缝——这不是矛盾，区别在于：
 抽象 ≠ 灵活；接缝 ≠ 提前实现。

4.4 自研 vs 采购

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


自研：完全可控、贴合业务、无授权费
 ✗ 要投入人力、要自己维护、要踩坑

采购/开源：成熟、快、社区支持
 ✗ 黑盒、受制于人、可能有授权/合规问题

 经验法则：
 核心竞争力、差异化能力 → 自研
 通用能力（消息队列、缓存、监控） → 用成熟方案
 不要重新发明轮子，除非轮子是你的核心业务。

五、两大反模式

5.1 不设计（Cargo Cult 抄作业）

1
2
3
4
5
6


"大厂都用微服务，我们也上微服务"
"别人用 K8s，我们也要 K8s"
→ 完全不看自己的规模、团队、问题

 这是把"别人的解"套到"自己的题"上。
 约束不同，照抄就是灾难。

5.2 过度设计（Resume Driven Development）

1
2
3
4
5


"我想在简历上写 K8s + Service Mesh + 事件驱动 + CQRS"
→ 一个日活 100 的内部系统，上了全套云原生

 简历好看了，系统难维护了，公司买单了。
 技术选型的依据应是"问题"，不是"我想学/想用"。

这两种病的共同点：决策没有回到约束和问题上。

六、架构是演进的，不是一次定死

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


架构的演进路径（也是本系列的主线）：

 单体 ──→ 模块化单体 ──→ 按领域拆分 ──→ 微服务 ──→ 云原生

 每一步升级，都是在"旧架构扛不住新约束"时才发生：
 单体扛不住团队规模 → 模块化
 模块化扛不住并发 → 拆服务
 服务多了扛不住运维 → 云原生

 关键：
 不要跳级。跳级 = 把未来的税提前交，还可能白交。
 能用单体解决的问题，上微服务就是自找麻烦。

这也是为什么第二篇我要先为单体正名——大多数人低估了单体，高估了微服务。

七、怎么做一个架构决策

给一个可落地的决策框架：

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


1. 把问题讲清楚
 不是"要不要上微服务"，而是
 "当前的痛点是什么？是发布耦合、扩容困难，还是团队协作？"

2. 列出所有候选方案
 至少 3 个。哪怕第 3 个是"什么都不做"。
 只有一个方案不叫决策，叫拍脑袋。

3. 对照四象限约束评估每个方案
 规模 / 时间 / 团队 / 成本
 列出每个方案的收益和代价（尤其是代价）。

4. 选定，并记录为什么放弃其他方案
 这一步最重要。用 ADR（Architecture Decision Record）记下来：
 - 背景、决策、理由、后果
 半年后你会感谢自己。

5. 留好回滚 / 演进的接缝
 决策可能是错的，约束会变。
 确保架构能"进"也能"退"。

八、小结

架构 = 在约束下分配职责的决策，画图只是产出
没有银弹：不存在最好的架构，只有当前约束下最合适的
约束四象限：规模、时间、团队、成本——架构决策永远依赖上下文
四大经典权衡：性能↔可维护性、一致性↔可用性、简单↔灵活、自研↔采购
两大反模式：不设计（照抄）、过度设计（简历驱动）
架构是演进的：单体 → 模块化 → 拆服务 → 云原生，不要跳级
决策要记录：用 ADR 写清"为什么这么选、放弃了什么"

下一篇，我先替"单体"说句公道话——模块化单体才是大多数团队被低估的最佳实践。