3. 业务平台架构工程方法论

智慧医院业务平台不是单一技术选型的产物,而是多种架构方法论在医疗场景下共同约束、相互裁剪的结果。理解这一节的关键,不是分别背诵五套名词,而是看清它们各自回答什么问题、在工程中落到哪些具体产物上,以及医疗行业的合规约束如何反向改写这些方法论的默认做法。

TOGAF:回答“为什么建、建成什么样”

TOGAF 提供的是企业级架构治理框架,核心是 ADM(架构开发方法)的迭代循环。在智慧医院项目中,真正被高频使用的是其中的架构内容框架与架构仓库:把业务架构、数据架构、应用架构、技术架构分层沉淀,形成可追溯的资产。例如门诊业务平台立项时,先产出业务架构中的“门诊就诊流程—业务能力—业务服务”三级映射,再据此推导应用架构中的服务边界,而不是先画微服务再补业务说明。

落地时建议至少固定三类产物:架构原则清单(如“患者主索引唯一”“临床数据不出院区”)、能力地图(挂号、缴费、报告、随访等能力项)、架构决策记录 ADR(记录选型理由与约束)。ADR 是 TOGAF 与后续微服务、云原生衔接的关键,它让“为什么这样拆”可被审计。

微服务架构:回答“怎么拆、怎么连”

微服务在医疗业务平台中的拆分依据不是技术便利,而是业务能力与数据所有权。以门诊域为例,可拆为挂号服务、排班服务、缴费服务、报告服务;每个服务独占其数据库,跨服务只通过接口或事件交互。拆分粒度可用“两个披萨团队能否独立交付”做粗判,但医疗场景更应看事务边界:挂号与缴费若强一致要求高,可先合并为“门诊交易服务”,待业务稳定后再按读模型拆分。

服务间通信优先采用同步 REST/gRPC 处理实时查询,异步消息处理状态变更。例如缴费成功后发布 PaymentCompleted 事件,由报告服务、随访服务订阅,避免缴费服务直接调用下游造成耦合。必须明确的是:分布式事务在医疗核心交易中应尽量避免,改用本地事务加事件最终一致,并配套对账与补偿任务。

中台化思想:回答“什么该复用、什么不该复用”

中台不是把所有系统推倒重建,而是把跨业务域重复出现的能力下沉为共享服务。医院中最典型的中台能力包括:患者主索引(EMPI)、统一认证与授权、消息通知、支付网关、字典与主数据、日志与审计。判断是否中台化,可用三个条件同时满足:被两个以上业务域使用、逻辑相对稳定、有明确的服务接口与 SLA。

反面案例是把“门诊挂号”做成中台——它只服务门诊域,且随政策频繁变化,应留在业务平台内。中台化的工程产物是能力清单 + 接口契约 + 版本策略,而不是一个叫“中台”的大系统。

云原生架构原则:回答“怎么运行、怎么演进”

云原生在医疗场景的落地要点是:容器化部署、声明式编排、可观测性、弹性与自愈。但医疗行业对可用性与数据驻留的要求高于一般互联网业务,因此需要做三点裁剪:

  • 多活与容灾:核心交易服务至少同城双活,数据库采用主备+只读副本,RPO 目标通常要求接近 0,RTO 控制在分钟级。
  • 可观测性:除指标、日志、链路外,必须增加业务级审计日志,记录谁在何时访问了哪份患者数据。
  • 配置与密钥:数据库口令、接口密钥不得写入镜像,统一由配置中心与密钥管理服务注入。

医疗行业架构约束与合规要求

医疗行业的约束会直接改写上述方法论的默认假设,主要体现在四类:

约束类型具体要求对架构的影响
数据安全与隐私患者数据分类分级、最小必要访问、脱敏与加密服务间调用需携带身份与授权上下文,敏感字段落库加密
等保与合规等保三级、数据出境限制、日志留存不少于6个月审计日志独立存储,网络分区与访问控制策略前置设计
业务连续性挂号、缴费、医嘱等核心链路不可长时间中断关键服务降级预案、熔断与限流阈值需按门诊高峰设定
标准与互操作HL7、DICOM、互联互通测评要求接口层需做标准适配,数据模型兼顾院内与区域平台

下面这张图把五类方法论在工程中的作用位置与衔接关系放在同一条链路上,便于判断每个问题该由哪套方法回答。

业务平台架构方法论的作用位置与衔接 TOGAF · 治理与分层 业务架构 → 数据架构 → 应用架构 → 技术架构;产出能力地图、架构原则、ADR 中台化 · 复用边界 EMPI、统一认证、支付网关、消息通知 判断条件:多域使用 + 逻辑稳定 + 有 SLA 微服务 · 拆分与连接 按业务能力与数据所有权拆分,独占数据库 同步查询 + 异步事件,避免分布式事务 云原生 · 运行与演进 容器化、声明式编排、可观测性、弹性自愈;医疗裁剪:同城双活、审计日志、密钥外置 医疗行业约束与合规 · 反向裁剪 数据分类分级与最小必要 · 等保三级与日志留存 · 核心链路连续性 · HL7/DICOM 互操作 影响:身份上下文随调用传递、敏感字段加密、审计独立存储、降级与限流阈值前置 约束反馈 工程衔接:TOGAF 定边界 → 中台定复用 → 微服务定拆分 → 云原生定运行 → 合规反向裁剪全部层级

把方法论落到一次真实拆分中

假设要建设“门诊业务平台”,可按以下顺序推进,每一步都对应具体产物:

  1. 用 TOGAF 定边界:梳理门诊域能力项,输出能力地图与架构原则,明确“患者主索引全院唯一”“缴费状态以交易服务为准”。
  2. 用中台化识别复用:EMPI、统一认证、支付网关、消息通知下沉为共享服务,输出接口契约与 SLA。
  3. 用微服务拆分:挂号、排班、缴费、报告各自独立,数据库独占;缴费成功发布事件,报告与随访订阅。
  4. 用云原生部署:容器化后由编排平台管理,配置与密钥外置,接入指标、日志、链路与审计四类可观测数据。
  5. 用合规反向校验:检查敏感字段是否加密、审计日志是否独立留存、核心链路是否有降级预案、接口是否符合 HL7/DICOM 适配要求。
判断方法论是否真正落地,不看文档厚度,而看三个可验证信号:服务能否独立部署、跨域能力是否有明确 SLA、审计日志能否还原一次患者数据访问的完整链路。
常见误区:把中台当成“大而全的系统”而非“能力集合”;把微服务拆到数据库共享;把云原生等同于“上容器”而忽略可观测性与合规审计。这三类问题在医疗场景中会直接放大为数据安全与业务连续性风险。

综上,TOGAF 管治理与分层,中台化管复用边界,微服务管拆分与连接,云原生管运行与演进,医疗合规则作为贯穿性约束反向裁剪所有层级。五者不是并列选项,而是一条从“为什么建”到“怎么运行”的完整工程链路。