架构与陷阱：把构件装进容器，并校准判断力

前七章造的是构件。本章问两个不同的问题：这些构件装在什么形状的代码结构里（架构），以及——更要紧的——这一摊业务到底该不该上全套 DDD（判断力）。前一半讲六边形/整洁/洋葱与两个补充模式（CQRS、事件溯源）；后一半把刀口转向自己，列出何时退回 CRUD，以及一张陷阱合集。贯穿全章的还是「云市」：销售上下文的 Order 聚合、它的 OrderRepository，以及库存上下文的 StockItem。

8.1六边形架构 / 端口与适配器 Hexagonal：依赖只指向内

六边形架构（Hexagonal Architecture，又名端口与适配器 Ports & Adapters）：领域在最里层、不依赖任何外部技术；所有数据库、HTTP、UI 都是外层适配器，源码依赖一律指向内。

底层机制（比文档深一层）：六边形的全部内容是一条依赖规则（dependency rule）——源码层面的 import 依赖只能指向内，最内层是领域模型，它不 import 任何东西（除了语言标准库）。问题随之而来：领域要存订单，怎么存？它又不许依赖数据库。答案是依赖倒置（Dependency Inversion）：领域层自己声明一个端口接口（如 OrderRepository），表达"我需要一个能存取订单的东西"；基础设施层写一个适配器（如 JpaOrderRepository）去 implements 这个接口。这样接口归领域、实现归基础设施，依赖箭头就从"基础设施"指向"领域"——而不是反过来。运行期靠 IoC 容器把适配器实例注入领域用到的端口（这正是 01 章 Spring 的 DI 在 DDD 里的位置）。

场景走查：OrderRepository 端口 + JpaOrderRepository 适配器

「云市」销售上下文要存订单。端口接口放在领域层，用领域语言说话（add / orderOfId，不是 save / findById）；JPA 适配器放在基础设施层，去实现它。

// 包: com.yunshi.sales.domain —— 领域层
// 不 import 任何 JPA / SQL / Spring 持久化类型。整个文件只认识领域概念。
public interface OrderRepository {
    void add(Order order);                 // 加入一个新聚合
    Order orderOfId(OrderId orderId);      // 按标识取回聚合
    void remove(Order order);
}

// 包: com.yunshi.sales.infrastructure —— 基础设施层
// 这里才允许 import JPA。它依赖领域（implements 领域的接口），领域不依赖它。
@Repository
public class JpaOrderRepository implements OrderRepository {

    private final OrderJpaMapper jpa;     // Spring Data 仓库，纯技术细节

    public JpaOrderRepository(OrderJpaMapper jpa) { this.jpa = jpa; }

    @Override
    public void add(Order order) {
        jpa.save(OrderRecord.fromDomain(order));   // 领域对象 ↔ 持久化记录互转
    }

    @Override
    public Order orderOfId(OrderId orderId) {
        return jpa.findById(orderId.value())
                  .map(OrderRecord::toDomain)
                  .orElseThrow(() -> new OrderNotFound(orderId));
    }

    @Override
    public void remove(Order order) { jpa.deleteById(order.id().value()); }
}

关键不在代码量，而在箭头方向：JpaOrderRepository 这个文件 import 了领域的 Order / OrderRepository；领域那个文件一行都没 import 基础设施。删掉整个基础设施包，领域仍能编译、仍能用内存假实现做单元测试。这就是"领域不依赖任何东西"落到 import 语句上的样子。

与下一节的关系：这条"依赖指向内"的规则不止六边形一种画法。整洁架构和洋葱架构画的是同一件事，只是换成同心圆。

8.2整洁 / 洋葱架构 Clean / Onion：同一规则的同心圆，且 ≠ DDD

整洁架构（Clean Architecture）与洋葱架构（Onion Architecture）是同一条依赖规则的同心圆表述；它们是交付机制，用了它们不等于在做 DDD。

底层机制（比文档深一层）：洋葱（Palermo）和整洁（Martin）都把代码画成同心圆——最内是领域模型/实体，外面一圈是应用服务/用例，再外面是接口适配器，最外是框架与驱动。圆环之间只有一条约束，和六边形那条字字相同：依赖只能从外指向内，内层不知道外层。换句话说，六边形、整洁、洋葱是同一规则的三种画法，不是三种架构。它们解决的是"代码怎么分层、依赖怎么摆"，属于怎么做（how）。

而 DDD 解决的是做什么（what）：和领域专家一起提炼统一语言（Ubiquitous Language）、按真正不变量划聚合（Aggregate）、在限界上下文之间做上下文映射（Context Mapping）。这些都是关于"模型长什么样"的决定，一行架构图都画不出来。所以——

与下一节的关系：上面三种架构都假设"读和写共用一个模型"。当读写的形状真正分叉时，CQRS 把这个假设拆开。

8.3CQRS：读写分模型，是补充不是前置

CQRS（Command Query Responsibility Segregation，命令查询职责分离）：写用领域模型走聚合保不变量，读用专门的查询模型直接拼成页面要的形状——两边是两套模型。

底层机制（比文档深一层）：CQRS 把命令（改状态）和查询（读状态）分给两套模型。命令侧：应用服务 load 出 Order 聚合、调方法、过仓储——这条路必须走聚合，因为它要保不变量、用乐观锁（05 章）。查询侧：直接对着读库或视图写 SQL，组装成 OrderSummaryView 这样的扁平 DTO，完全绕过聚合和仓储，不经过任何领域不变量。轻量做法（CQRS-lite）两侧共库，只是分两条代码路径；重量做法两侧分库，写库发事件、读库异步投影，于是引入最终一致（07 章那条线又出现了）。

与下一节的关系：CQRS 的重量版要写库发事件。再往前一步——干脆只存事件、不存当前状态——就是事件溯源。

8.4事件溯源 Event Sourcing：按需用，且 Kafka 不是事件存储

事件溯源（Event Sourcing）：不存对象的当前状态，只存它经历过的事件序列；当前状态靠把事件依次重放（replay）算出来。

底层机制（比文档深一层）：聚合的每一次状态变更都先产出一个领域事件（OrderPlaced、OrderPaid、StockReserved……，命名仍用 07 章的过去式），按发生顺序追加进事件存储。要取回聚合当前状态，就把它的事件序列从头重放。这天然带来审计、时间旅行、按需重建读模型的能力。代价也实打实：查询当前状态要重放（常配快照优化）、事件 schema 演化很难、整个团队的心智模型要换。所以——

与下一节的关系：CQRS、事件溯源都是"按上下文、仅核心域投入"的局部决定。同样的克制，要用在一个更大的边界上——限界上下文和微服务的关系。

8.5限界上下文 ≠ 微服务 1:1：服务从边界涌现

一个限界上下文可以、但不必对应一个微服务；模块化单体优先，服务在有真实部署/扩展/团队压力时才从边界涌现。

底层机制（比文档深一层）：限界上下文（03 章）是语义/模型边界——同一个词在边界两侧是不同的类（「云市」的 Product 在 Catalog 是胖展示对象、在 Sales 是下单快照）。微服务是部署/运行时边界——能独立部署、独立扩展、独立数据库、独立团队负责。这是两个维度：前者关于代码怎么建模，后者关于进程怎么切分。它们可以对齐，但不强制 1:1。

当前共识（2026）已经把硬规则推翻，换成更克制的顺序：

• 先做模块化单体（modular monolith）：上下文之间用模块/包边界划清，进程内调用，一套部署。边界在代码里是真实的，运维成本却接近单体。
• 让服务从边界涌现：当某个上下文出现真实的独立部署节奏、独立扩展需求（如库存上下文流量是订单的十倍）、或独立团队所有权时，再沿那条已经划好的上下文边界把它切出去成一个服务。
• 边界划对了，这一刀很好切；边界没划对，拆成微服务只是把烂泥摊到网络上。所以先把上下文边界做对，比先拆服务重要得多。

与下一节的关系：以上全是"上了 DDD 之后怎么摆"。但有一个更前置的问题没问——这摊业务到底该不该上 DDD。

8.6何时不用 DDD：退回事务脚本 / CRUD

通用域、支撑域、短命工具、拿不到领域专家的场景，应退回事务脚本 / Active Record / CRUD 脚手架；对这类子域，贫血 + Service 层是合理默认。

底层机制（比文档深一层）：三个信号指向"退回简单做法"——

• 子域类型是通用/支撑：通用域（如「云市」的发票、对账）能买就买、能用现成框架就用；支撑域（如运营后台、字典维护）逻辑浅，CRUD 足够。只有核心域（Sales 的下单与定价）值得全套。
• 短命工具 / MVP：活不过半年的内部脚本、待验证的原型，建模投资来不及回本。
• 没有领域专家：统一语言要和懂业务的人共建。没有专家，提炼不出真正不变量，建出来的"聚合"是凭空想象，还不如老实 CRUD。

退回的具体形态：事务脚本（Transaction Script）——一个用例一段过程式代码，从上到下把这件事办完；Active Record——对象直接映射一行表、自带增删改查；CRUD 脚手架——框架按表生成的标准增删改查。对这些子域，OrderController → OrderService → OrderDao 这种贫血对象 + Service 层结构是合理默认，不是反模式。

与下一节的关系：把上面所有判断浓缩成一张表——常见陷阱各自的根因和修复。

8.7常见陷阱合集：根因 → 修复

把前八章踩过的失败模式列在一张表里：每一行先点根因（违反了哪条原则），再给修复方向。

七行陷阱可以归到一句话：DDD 的每个构件都对应一条原则，越界用就成陷阱。聚合对应一致性边界、依赖规则对应技术隔离、领域事件对应业务事实、全套 DDD 对应核心域投资——把它们用在违背各自前提的地方，就是这张表里的每一行。