避免巨石流程：流程模型必须完全归属一个上下文

端到端业务流程往往会跨越多个限界上下文（订单履约就会牵涉支付确认和货物运输），但这不意味着可以设计一个”无所不包”的流程模型——流程模型是领域逻辑，必须完全在一个上下文中，应该包含在实现该上下文的服务里，而不应该需要跨上下文的内部知识才能运行。书中用”库存不足触发采购子流程”的BPMN例子说明反面教材：这种设计只在极特殊场景下合理（消费者订单几乎全是定制商品，必须逐笔确认可购买性，这时订单履约和采购放进同一上下文甚至同一服务才说得通）；但现实中订单履约服务通常应该假设商品有货，库存不足时最多是流程停留等待，而不该负责采购或管理商品目录——采购决策应交给独立监控库存、预测需求的库存服务。把跨上下文的细节（比如支付服务内部的具体逻辑）混进同一个流程模型，就会形成”巨石流程”：这类模型突破了各服务的边界、侵犯了对应服务的所有权，组织里找不到一个人能对它全权负责，任何相关服务的变更都要牵连修改这个模型，还会因为混用不同上下文的术语而破坏统一语言。正确做法是把端到端流程拆成更小的组件、分别融入各自的服务——不只是像BPMN子流程那样加一层结构，更要把职责实际分配给不同服务，让订单履约流程完全不需要关心支付的具体细节，只依赖支付服务给出的最终结果（成功/失败）。