将逻辑提取到子流程的取舍：分而治之与复用性两难

在同一个服务边界内部，也存在”哪部分逻辑该留在主流程模型里、哪部分该提取成独立子流程”的判断——这不同于[[纯文本流程建模方案的表达力局限与代码到图形的过渡策略]]讨论的”模型还是代码”，也不同于跨服务边界拆分的问题，而是同一边界内的建模粒度选择。书中给出的具体场景：CRM系统的API很笨拙，必须先创建用户再异步发送用户数据、还要等待结果，且这个遗留系统响应慢、消息还可能因中间件bug而丢失——把这些技术细节全部提取进一个独立的子流程模型，再从主流程（如用户入网流程）里调用它，能避免这些细节”污染”主流程，让主流程里所有任务保持相近的细节层级，更容易阅读，这是分而治之策略的直接体现。提取子流程还有另一个理由：可复用性——如果流程模型的多个地方都要用到”CRM创建用户”这个逻辑，值得思考的是该在流程模型层面复用（做成可被多处调用的子流程），还是干脆构建一个全局可用、有合适API、调用方完全不需要关心背后是否用了工作流引擎的独立服务（呼应第7章讨论的服务边界思路）；但要记住BPMN子流程只有在所有逻辑都处于同一边界内时才合理。至于什么时候该提取子流程，作者认为没有硬性规定，就像编程里”什么时候该把代码重构成独立方法”没有硬性规定一样，很大程度上是品味问题：偏好大模型、靠建模惯例维持可读性的人，风险是模型对读者造成压迫感；偏好拆大量子流程、追求干净主流程的人，风险是读者要在很多模型间来回跳转，某些场景（比如取消请求需要反向传播）还会让建模本身变得更难。作者的建议是：能不用子流程就尽量不用，但如果确实存在明显不同粒度层级的逻辑，就该引入子流程，因为这能带来更容易理解的流程模型。