2. 识别系统内外部边界的方法论

系统内外边界的准确划定是架构设计的基石。本章围绕四种经过大规模系统验证的方法论展开，覆盖从业务认知到技术落地的完整链条。每种方法应对不同类型的边界模糊场景，组合使用可获得高置信度的边界划分结果。

2.1 业务域分析

业务域分析从组织战略目标出发，将业务能力拆解为独立的域（Domain），每个域拥有明确的业务范围和语言体系。该方法适用于从零开始的系统规划或大规模遗留系统重构时的顶层边界识别。

具体操作分为五个步骤：

1. 事件梳理：采访业务专家，列出业务全生命周期中发生的关键业务事件（如“订单已支付”“库存已扣减”）。
2. 角色与职责映射：为每个事件关联执行角色（系统/人），明确职责边界。
3. 业务对象提取：从事件和角色交互中提炼业务对象（如“订单”“支付单”），记录其属性和行为。
4. 域划分：将高内聚、低耦合的业务对象和事件归入同一个域，识别域间依赖关系。
5. 限界上下文确认：为每个域划定模型边界，确保域内术语唯一、逻辑自治。

2.2 上下文映射

上下文映射用于处理已识别域之间的协作关系。它不回答“是什么”，而是回答“怎么对接”。映射结果直接决定集成架构、数据同步策略和API协议设计。

常见上下文映射模式及对应的架构决策：

• 合作关系（Partnership）：两个域共同演化变更，适合高频协作场景。推荐采用事件驱动或共享内核模式，需设计双向版本兼容。
• 防腐层（Anti-Corruption Layer, ACL）：下游域需要接入上游域模型但不想被污染。在下游边界处实现翻译层，隔离领域模型的差异。
• 开放主机服务（Open Host Service）：上游域以稳定协议发布服务接口，下游仅按协议调用。典型的REST/gRPC对外接口场景。
• 发布语言（Published Language）：双方基于统一的数据交换格式（如JSON Schema/Protobuf）通信，减少翻译成本。

映射过程推荐在REST API或事件Schema上显式标记上下文归属，例如在API网关层或事件头部注入x-context-id。

// 防腐层示例：下游订单域调用上游支付域时的模型翻译
// downstream/order/acl/PaymentTranslator.java
public PaymentNotification translateFromUpstream(PaymentResponse upstream) {
    return PaymentNotification.builder()
        .paymentId(upstream.getPaymentId())
        .status(toOrderStatus(upstream.getPayState()))
        .amountInFen(upstream.getTotalAmount())
        .settledAt(upstream.getCompleteTime())
        .build();
}

2.3 事件风暴

事件风暴是一种工作坊式的协作建模方法，通过快速识别“领域事件”来发现聚合边界和限界上下文。适合在业务逻辑复杂、多方理解不一致时使用，通常由架构师主导、业务专家和开发人员共同参与。

实施流程分为四个阶段：

1. 风暴阶段（15-30分钟）：用橙色便利贴写出所有能想到的领域事件（过去时态动词），如“用户已注册”“商品已上架”“订单已取消”。不讨论顺序，只做发散。
2. 排序阶段：将事件按业务时序从左到右排列，形成时间轴。发现缺失的事件（如“支付已超时”）可直接补充。
3. 聚合发现：围绕事件找出触发它的命令（蓝色便利贴）和涉及的角色（黄色便利贴），将高度相关的多个事件和命令封装成一个聚合（Aggregate）。聚合即边界的原型。
4. 上下文分组：将关联性强的聚合再次组合为限界上下文，不同上下文之间用边界线隔开。此时若发现事件横跨多个上下文，即为集成点。

事件风暴的产出物包括：领域事件-命令矩阵、聚合划分表、限界上下文关系图。这些直接转化为微服务或模块边界。

# 领域事件示例（事件风暴后的事件定义）
event InventoryReserved {
    string orderId
    string skuId
    int32 reservedQuantity
    timestamp occurredAt
}

event StockConfirmed {
    string inventoryId
    string skuId
    int32 availableQuantity
    timestamp occurredAt
}

2.4 用户故事裁剪

用户故事裁剪是一种从外部需求反向推导边界的轻量级方法。它以用户故事的粒度作为基准，判断一个功能应该放在系统内部还是外部，以及属于哪个子系统。

核心判断规则：

• 故事内聚性：如果某个用户故事的全部步骤可以在同一个模块/服务内完成，且不依赖外部系统（或依赖可通过API简化），则属于内部边界。
• 故事间耦合：两个故事如果共享相同的数据对象集合或事务边界，则应放入同一个边界内部。
• 故事变更频率：变更频繁的故事与稳定故事之间应设立防变层（ACL），分别放在不同边界中。
• 故事专用性：仅为单一用户角色服务的专属功能，倾向于独立成边界。

在实际操作中，可用用户故事映射表进行边界判断：

2.5 四种方法论的协同运用

四种方法不是孤立的，应顺序组合使用：

1. 自上而下：先用业务域分析画出宏观地图，识别核心域、支撑域和通用域。
2. 横向细化：利用上下文映射为域间的协作模式定调（事件驱动/API/消息队列）。
3. 深层聚焦：对有争议或高复杂度的域引入事件风暴，发现更细粒度的聚合边界。
4. 反向验证：所有产出物回到用户故事裁剪中进行穿透验证，确保每个用户故事有清晰的归属边界。

下面的SVG展示了四种方法与边界识别流程的对应关系：

2.6 落地步骤与验收标准

在架构方案中，四种方法论的落地应遵循以下步骤：

1. 启动工作坊：组织业务、产品、开发三方，按2.1→2.2→2.3→2.4顺序依次开展，每阶段不少于1个工作日。
2. 产出物评审：每个阶段结束必须产出对应的矩阵、关系图或事件表，评审通过后方可进入下一阶段。
3. 边界清单确认：最终输出《系统边界划分清单》，包含每个边界的名称、所属域、上下文映射模式、核心用户故事列表。
4. 集成方案草稿：根据上下文映射模式编写初步的集成方案（API/事件/消息），不要求完整实现，但需要明确数据流方向。

验收标准：

• 每个识别出的边界在《边界划分清单》中有唯一ID，且与至少一个用户故事对应。
• 任意两个边界的耦合度 ≤ 3（通过依赖分析工具验证，如JDepend、ArchUnit）。
• 事件风暴产出的领域事件在后续实现中覆盖率 ≥ 90%（即90%的事件被实现为消息或API端点）。
• 用户故事裁剪的结果：不存在一个用户故事同时归属于3个及以上边界的情况。