3. 业务中台建模方法论

在医疗业务中台的建模实践中，方法论的选择往往比工具本身更关键。领域驱动设计（DDD）、业务能力地图、服务化建模、事件风暴这四类方法各有侧重：有的擅长划分边界，有的擅长梳理能力，有的擅长定义接口，有的擅长发现事件。把它们混为一谈，或者在任何场景下都套用同一种方法，是导致中台模型“看起来完整、用起来割裂”的常见原因。本节先厘清每种方法解决的核心问题，再给出组合选择的判断依据。

四类方法各自解决什么问题

领域驱动设计关注的是“边界在哪里”。它通过限界上下文（Bounded Context）把复杂的医疗业务切成若干语义自洽的模块，例如“门诊挂号”“住院医嘱”“检验检查”“收费结算”可以各自成为限界上下文。DDD 的核心产出是上下文映射图、聚合根、实体与值对象。它最适合处理业务规则复杂、术语容易混淆的领域，比如“医嘱”在住院和门诊语境下含义不同，必须通过限界上下文隔离。

业务能力地图关注的是“中台应该提供哪些能力”。它从医院战略和业务价值链出发，把能力逐层分解为一级能力域、二级能力组和三级能力项。例如“患者服务”能力域下可分解出“建档”“预约”“签到”“随访”等能力项。能力地图不关心技术实现，只回答“做什么”，因此适合在项目早期统一业务与 IT 的认知，也适合作为中台服务规划的顶层框架。

服务化建模关注的是“能力如何变成可复用的服务”。它把能力地图中的能力项进一步设计为服务契约，明确输入、输出、幂等性、事务边界和版本策略。例如“患者建档”服务需要定义患者标识生成规则、必填字段、重复建档的判定逻辑。服务化建模直接决定中台 API 的质量，适合在边界和能力基本确定后开展。

事件风暴关注的是“业务过程中发生了什么”。它通过领域事件、命令、聚合和策略的贴纸推演，快速暴露业务流程中的关键状态变化和协作关系。在医疗场景中，事件风暴特别适合梳理“挂号→就诊→开单→收费→执行→报告”这类跨科室长流程，因为它能直观呈现事件之间的因果链和时序依赖。

方法选择的判断依据

选择方法时，可以从三个维度判断：业务复杂度、组织协作范围和当前阶段目标。如果业务规则密集、同一术语在不同科室含义不同，优先用 DDD 划清限界上下文；如果目标是向院领导或信息科说明中台建设范围，业务能力地图更直观；如果流程跨多个科室且状态变化频繁，事件风暴能快速暴露隐藏的协作断点；如果已经明确要对外提供 API，服务化建模则不可跳过。

需要强调的是，这四类方法不是互斥的，而是有先后和嵌套关系。典型组合是：先用业务能力地图确定中台能力范围，再用 DDD 为每个能力域划定限界上下文，接着用事件风暴在上下文内部推演业务流程和领域事件，最后用服务化建模把关键能力固化为服务契约。这个顺序并非铁律，但符合“从战略到战术、从粗到细”的认知规律。

医疗场景中的组合示例

以“门诊就诊”中台建模为例。第一步，业务能力地图列出“患者服务、挂号服务、就诊服务、收费服务、药事服务”五个能力域。第二步，DDD 将“就诊服务”划为一个限界上下文，聚合根为“就诊记录”，实体包括“主诉”“诊断”“医嘱”。第三步，事件风暴推演：患者签到 → 分诊叫号 → 医生接诊 → 开立医嘱 → 医嘱收费 → 药房发药，每个节点标注领域事件和命令。第四步，服务化建模把“开立医嘱”设计为服务，契约中明确：输入为就诊号、医嘱项、剂量、频次；输出为医嘱号、状态；幂等键为“就诊号+医嘱项+开立时间”；事务边界为“医嘱写入与费用预占在同一本地事务”。

常见误区与规避

第一个误区是“用能力地图代替 DDD”。能力地图是静态的能力清单，无法表达业务规则和状态变化，直接拿能力项去建服务，容易得到一批贫血的 CRUD 接口。第二个误区是“事件风暴只画流程”。事件风暴的价值在于发现聚合边界和策略，如果只画成流程图，就丢掉了“哪些事件必须原子发生”“哪些事件可以最终一致”这些关键判断。第三个误区是“服务化建模过早”。在限界上下文尚未稳定时定义服务契约，后续边界调整会导致大量接口返工。

规避方式也很直接：能力地图用于沟通，DDD 用于划界，事件风暴用于验证，服务化建模用于交付。每个阶段都有明确的产出物和验收标准，例如 DDD 阶段验收“上下文映射图无循环依赖”，事件风暴阶段验收“每个领域事件都有明确的触发命令和后续策略”，服务化建模阶段验收“每个服务契约都有幂等键和事务边界说明”。

方法适用性速查

最后需要提醒的是，方法论的选择要服务于项目目标，而不是反过来让项目去迁就方法论。在医疗业务中台这种多科室、多系统、强监管的环境中，最稳妥的做法是：用能力地图统一语言，用 DDD 守住边界，用事件风暴对齐时序，用服务化建模保证复用。四者配合，才能让中台模型既“看得懂”又“接得上”。