# 架构决策记录：建立 DIB 统一方案工作空间

日期：2026-06-02
状态：已采纳
决策编号：ADR-2026-06-02-001

## 1. 背景

当前关于 DIB 数智桥、云医疗业务平台、DIB Client、DIB Agent、院长看板、转诊服务、HL7/FHIR、ICD-10 等想法分散在多个独立项目中，包括：

```text
C:\dev\digital-intelligence-bridge
C:\dev\cloud-medical-platform
C:\dev\allinone-president-dashboard
C:\dev\allinone
```

这些项目都尚未正式上线，仍属于初步探索阶段。继续分散推进会带来以下成本：

1. 顶层定位不统一。
2. 术语命名不统一。
3. 平台能力和业务能力边界容易混淆。
4. Agent、资源中心、插件中心和云医疗后端可能重复设计。
5. 后续领导汇报、团队开发和项目迁移成本增加。

## 2. 决策

建立统一方案工作空间：

```text
C:\dev\dib-platform
```

该工作空间先作为 DIB 数智桥平台的顶层方案空间，不立即搬迁旧项目代码。

首批目录：

```text
C:\dev\dib-platform\docs\architecture
C:\dev\dib-platform\docs\glossary
C:\dev\dib-platform\docs\roadmap
C:\dev\dib-platform\docs\decisions
```

首批文档：

```text
docs\architecture\dib-platform-overall-architecture-blueprint.md
docs\glossary\dib-platform-glossary.md
docs\roadmap\dib-platform-phase1-mvp-roadmap.md
```

## 3. 核心架构口径

统一采用以下顶层定位。2026-06-13 口径修订：数智桥定位从单一省级平台扩展为国家、省、市、县等多层级可部署的融合底座，省级平台作为典型样板实例保留。

```text
多层级 DIB 数智桥平台：一底座、多专区、统一接入、标准互通、集约运营
```

统一分层：

```text
DIB Platform Core
DIB Client
DIB Agent
DIB Industry Suites
```

其中：

1. DIB Platform Core 是可按国家、省、市、县等层级部署的统一底座，承载资源中心、插件中心、发布中心、组织/站点治理、权限审计、标准互操作、Agent 调度和运行监测。
2. DIB Client 是机构侧插件宿主和本地工作台。
3. DIB Agent 是机构内部资源与 DIB 服务端之间的安全连接器。
4. DIB Industry Suites 是行业专区，首批重点为 DIB Medical Suite，后续扩展 DIB 医保 Suite、DIB 疾控 Suite 等。

## 4. 不立即合并代码的原因

当前不建议立刻把旧项目代码搬入 `C:\dev\dib-platform`，原因如下：

1. 现有项目仍处在探索阶段，边界尚未完全稳定。
2. 直接合并代码容易把旧命名、旧假设和临时实现一起固化。
3. 各项目技术栈和职责不同，强行合并会增加构建、测试和版本管理复杂度。
4. 当前更紧迫的是统一顶层架构、术语、路线图和迁移策略。

因此采用：

```text
先统一思想和目录
再统一新开发入口
最后按模块迁移旧代码
```

## 5. 现有项目处理原则

| 项目 | 当前处理方式 |
| --- | --- |
| digital-intelligence-bridge | 作为 DIB Platform Core、DIB Client、DIB Agent 的主要探索资产 |
| cloud-medical-platform | 作为 DIB Medical Suite 的主要探索资产 |
| allinone-president-dashboard | 作为院长看板 SQL 口径和业务监管支撑的迁移基线 |
| allinone | 作为旧 HIS 入口、数据源和回写目标的参考资产 |

短期不移动代码，只在统一工作空间中记录归属和迁移路线。

## 6. 后续演进路径

### 阶段一：统一方案

1. 建立总蓝图。
2. 建立术语表。
3. 建立一期 MVP 路线图。
4. 建立领导汇报口径。
5. 建立现有项目归属清单。

### 阶段二：统一新开发

新开发逐步进入 `C:\dev\dib-platform`，按以下结构演进：

```text
C:\dev\dib-platform
├─ docs
├─ platform-core
├─ dib-client
├─ dib-agent
├─ suites
│  ├─ medical
│  ├─ insurance
│  └─ cdc
└─ legacy-references
```

### 阶段三：迁移旧代码

在一期 MVP 闭环稳定后，再按模块迁移旧项目代码。迁移时必须满足：

1. 目标模块边界清楚。
2. 有迁移前后测试或验收依据。
3. 不混入无关历史实验代码。
4. 每次迁移都有明确归属和回滚路径。

## 7. 决策影响

正面影响：

1. 统一顶层叙事，便于领导汇报。
2. 统一术语和边界，降低团队沟通成本。
3. 降低过早合仓带来的技术债风险。
4. 为后续多专区扩展保留空间。
5. 让 DIB 从单一客户端项目提升为多层级平台底座。

需要注意：

1. 文档空间不是最终代码仓库结构。
2. 旧项目仍需维护现有探索成果，不能简单废弃。
3. 后续必须建立迁移清单，否则统一工作空间可能变成纯文档孤岛。

## 8. 当前结论

本决策确认：

```text
C:\dev\dib-platform 是 DIB 数智桥平台的统一方案工作空间。
当前阶段只落文档和架构决策，不迁移旧代码。
后续新开发和旧代码迁移必须以总体架构蓝图和一期 MVP 路线图为依据。
```