复杂业务架构
复杂业务系统通常不是“一个页面加几个组件”，而是由工作台、页面生命周期、权限、上下文、数据服务、审计、诊断和高性能组件共同组成。DirectSurface UI 的职责是提供这些能力的承载结构，不定义医院、患者、订单、病历等业务模型。
分层建议
推荐把系统拆成四层：
业务入口
工作台、路由、菜单、登录态、全局服务
业务页面
查询页、维护页、编辑页、弹窗、浮动窗口
框架能力
RenderObject、布局、组件、上下文、命令、权限、诊断、弹层
业务服务
API 客户端、缓存、权限服务、审计服务、字典服务、模板服务
业务入口负责把全局上下文和基础服务注入应用。业务页面只组合组件和服务，不直接改框架内部状态。框架能力只提供通用机制，不知道具体业务状态。业务服务封装接口协议、权限规则和持久化行为。
页面边界
复杂系统中最容易失控的是“页面之间互相拿对象”。推荐用页面作为生命周期边界：
- 页面打开时创建局部上下文和页面级命令。
- 页面关闭时释放上下文、命令、订阅、缓存和弹层。
- 弹窗优先继承调用页面上下文，而不是直接依赖全局变量。
- 浮动窗口如果升级为顶级窗口，应明确重新注入所需上下文。
这样可以避免关闭 tab 后对象仍被全局引用，也能让同一个业务页面在多个患者、多个院区或多个租户下同时打开。
框架不做什么
框架不应该内置 CIS、HIS、EMR 的具体业务对象。比如当前患者、就诊号、医嘱状态、病历归档状态都应该由业务定义，然后通过上下文或页面状态注入。
框架可以提供：
- 上下文注册和查找。
- 命令注册、权限判断和启用状态。
- 可销毁的页面范围。
- 高性能表格、树、大文本和病历编辑器。
- 运行时诊断和对象查看。
框架不直接提供：
- 业务权限编码规则。
- 患者主索引结构。
- 医疗文书生命周期。
- 审签、归档、质控的业务流转。
这些内容属于业务系统，应该在业务服务和页面组合层完成。
推荐接入流程
- 先定义应用级上下文：登录用户、租户、权限服务、字典服务、通知服务。
- 再定义页面级上下文：当前业务对象、页面参数、页面缓存、页面命令。
- 所有按钮、菜单、快捷键走统一命令。
- 所有业务状态改变走页面状态和服务，不让组件互相直接调用。
- 所有长生命周期对象都放入可释放范围。
- 性能问题优先用运行时诊断定位，再判断是布局、绘制、数据量还是业务回调。
复杂系统的稳定性来自边界清晰。组件越通用，业务就越应该通过上下文、命令和服务把规则放在外层。