4. 系统总体架构设计

医生工作站系统不是单一应用，而是由门诊医生站、住院医生站、电子病历、医嘱、检验检查申请、护理协同、临床决策支持等多个业务域共同构成的临床工作平台。总体架构设计要回答四个问题：系统按什么层次组织、服务按什么粒度拆分、前端与后端如何解耦、各业务域之间通过什么通道集成。这四个问题相互制约，任何一项选错都会在后期以性能、交付或运维代价的形式暴露出来。

一、分层架构：把变化隔离在可控范围内

推荐采用五层结构，自上而下为接入层、网关层、应用服务层、领域能力层、数据与集成层。接入层承载医生工作站桌面客户端、浏览器端、移动查房端；网关层统一处理认证、路由、限流与审计；应用服务层按业务域组织服务，如医嘱服务、病历服务、患者主索引服务；领域能力层沉淀可复用的临床能力，如术语映射、剂量校验、权限判定；数据与集成层负责业务库、临床数据中心以及对外部系统的适配。

分层的核心价值是约束依赖方向：上层可调用下层，下层不得反向依赖上层。例如医嘱服务需要调用剂量校验能力，应通过领域能力层暴露的接口，而不是直接读取病历服务的数据库表。这条约束在项目初期看似繁琐，但能避免后期出现“改一处、崩一片”的连锁故障。

二、微服务与单体架构选型：按业务域和团队规模决策

选型不应追求技术先进性，而应匹配业务复杂度与团队交付能力。医生工作站系统常见的三种策略如下：

对多数医院自建或区域统建项目，建议采用“模块化单体起步、按域渐进拆分”的路线。例如先以单体交付门诊医生站，但代码中按医嘱、病历、患者三个模块划分包结构并禁止跨模块直接访问数据表；当住院医生站、护理站接入后，再把医嘱模块独立为服务。这样既避免了一次性微服务化带来的分布式复杂度，又保留了演进空间。

三、前后端分离：接口契约先行

前后端分离的关键不是“前端用框架、后端出JSON”，而是接口契约先行。医生工作站前端需要展示患者基本信息、诊断列表、医嘱列表、检验检查结果等，后端应提供稳定的资源接口，而不是为每个页面定制接口。建议按资源组织URL，例如：

GET  /api/v1/patients/{patientId}            获取患者主索引
GET  /api/v1/patients/{patientId}/orders     查询患者医嘱列表
POST /api/v1/orders                          提交新医嘱
GET  /api/v1/orders/{orderId}/audit-trail    查询医嘱操作留痕

接口需明确分页、排序、错误码和字段脱敏规则。例如医嘱列表默认按开立时间倒序，每页20条；患者身份证号在非授权角色下返回掩码。前端通过统一请求层处理令牌刷新与错误提示，避免每个页面重复实现。

四、接口网关与系统集成策略

网关是医生工作站与外部系统之间的唯一入口，承担路由、鉴权、限流、协议转换和日志审计。典型集成对象包括HIS、LIS、PACS、医保结算、区域健康档案平台。集成策略按实时性分为三类：实时同步用于患者主索引、医嘱状态回写；准实时消息用于检验检查报告到达通知；批量抽取用于运营统计与科研数据。网关需为每类外部系统配置独立的超时与熔断阈值，例如LIS查询超时设为3秒、失败后降级为“报告未回”提示，而不是阻塞医生开立医嘱。

图中纵向箭头表示依赖方向，上层调用下层；底部橙色箭头表示与外部系统的集成通道，由集成适配器统一封装协议差异。网关层位于接入层与应用服务层之间，所有外部请求必须经过网关，不允许前端直接访问应用服务。

五、落地时的关键判断

架构设计完成后，需要用可验证的方式确认它是否成立。第一，检查是否存在跨层调用：如果医嘱服务直接查询了病历服务的表，说明分层约束失效。第二，检查网关是否覆盖全部入口：如果移动查房端绕过网关直连服务，认证与审计将出现缺口。第三，检查接口契约是否稳定：如果前端每新增一个页面就要求后端新增一个专用接口，说明资源抽象不足。第四，检查集成超时是否可控：如果LIS查询超时未设置，一次外部系统抖动就可能拖垮医嘱开立主流程。

总体架构不是一次性设计完成的静态图纸，而是随业务域接入、团队规模变化和外部系统演进而持续调整的约束框架。对医生工作站系统而言，最重要的不是选择了微服务还是单体，而是分层边界是否清晰、接口契约是否稳定、集成通道是否可控。这三点决定了系统在门诊高峰、多院区协同和外部系统故障时能否保持可用。