聚合边界与限界上下文边界的两层边界体系

DDD构建领域模型和划分微服务边界，依靠事件风暴工作坊方法，先经历一个从发散到收敛的过程：发散阶段通过用例分析、场景分析、用户旅程分析，尽可能全面地梳理业务领域中的命令、领域事件、领域对象及其业务行为；收敛阶段把发散阶段提取出的实体、值对象、聚合根等，从不同维度聚类，形成聚合和限界上下文这两层边界。这两层边界的性质完全不同：聚合边界是同一个限界上下文内、业务紧密相关且相互依赖的实体组合形成的边界，这是微服务内部的第一层边界，同一个限界上下文里的多个聚合仍运行在同一个微服务实例内，因此这层边界只是逻辑边界（图中习惯用虚线表示）；限界上下文边界则是把一个或多个聚合圈定在一起、划出的第二层边界，不同限界上下文内的领域模型业务逻辑会被隔离到不同的微服务实例中运行，物理上相互隔离，因此这层边界是物理边界（图中习惯用实线表示），并且未来往往就是真正的微服务边界。理解这两层边界的关键在于：聚合边界解决的是”同一个服务内部，哪些对象该聚在一起被当作一个整体来维护一致性”，限界上下文边界解决的是”哪些聚合该被拆到不同的服务里独立部署和演进”，前者是后者的构建材料，但两者的隔离强度（逻辑vs物理）完全不是一个量级。

结构图：

flowchart TB
    subgraph BC1["限界上下文A（物理边界＝未来的微服务边界）"]
        direction TB
        subgraph AGG1["聚合1（逻辑边界）"]
            Root1["聚合根"] --- E1["实体"]
            Root1 --- V1["值对象"]
        end
        subgraph AGG2["聚合2（逻辑边界）"]
            Root2["聚合根"] --- E2["实体"]
        end
    end
    subgraph BC2["限界上下文B（物理边界＝另一个微服务）"]
        direction TB
        subgraph AGG3["聚合3（逻辑边界）"]
            Root3["聚合根"] --- E3["实体"]
        end
    end
    BC1 -. "物理隔离，跨进程通信" .-> BC2