01 三层分层:内核 / 外壳 / 领域

01 三层分层:内核 / 外壳 / 领域

本节摘要:OpenWork 的前端是一个规模可观的 React 单页应用。它怎么组织才不乱?靠一套清晰的三层分层:内核层(kernel,平台与服务 provider)、外壳层(shell,应用骨架与协调)、领域层(domains,业务模块)。本节讲清这三层的职责边界与依赖规则——这是前端可维护的根基。

一、规模带来的组织挑战

先看挑战。OpenWork 前端要支持:

• 会话界面(聊天、产物、终端)
• 工作区管理
• 设置
• 连接、引导、云等多个业务模块
• 同时跑在浏览器和桌面(Platform 抽象,第 02 节)
• 通过 desktopBridge 调主进程(第 9 章)
• 通过 HTTP 调服务端

这么多东西放一起,如果没有清晰组织,很快会变成「大泥球」——改一处牵全身,没人敢动。三层分层就是解法。

二、三层一览

OpenWork 前端分三层(外加一个框架无关层):

src/app/          框架无关层(禁止 import react)
   └─ lib/        IPC/服务端/Den 客户端(纯逻辑,无 UI)
src/react-app/
   kernel/        内核层:Provider 栈 + 平台 + 通知 + 系统状态
   shell/         外壳层:Bootstrap/路由/命令面板/菜单(顶层)
   domains/       领域层:session/workspace/settings/connections/cloud/onboarding
   infra/         基础设施:query-client 等
   design-system/ 设计系统:展示型原语
​

三、框架无关层(app/):纯逻辑

最底层是框架无关层(app/)——它禁止 import react。这里放的是纯逻辑:

• IPC 客户端(desktopBridge,调主进程)
• 服务端客户端(调服务端 API)
• Den 客户端(企业版)
• 其他纯逻辑工具

为什么禁止 react?因为这些是「逻辑」,不该和「UI 框架」耦合。逻辑不依赖 react,就能在任何地方(测试、Node、其他框架)复用。这是「逻辑与 UI 分离」的严格落地。

💡 禁止 import react 的强制性:这不是「建议」,是 madge(依赖分析工具)强制检查的——app/ 里 import react 会报错。这种强制保证了「逻辑层纯净」。

四、内核层(kernel):Provider 栈

内核层是前端的「基础设施栈」,放各种 Provider(为上层提供能力的组件):

• 平台 Provider(Platform,第 02 节)——提供 web/desktop 环境抽象
• 服务端 Provider——提供调服务端的能力
• 全局 SDK Provider——全局 SDK 能力
• 全局同步 Provider——数据同步(如 Reload 事件轮询)
• 本地偏好 Provider——本地设置
• 通知 store——通知状态

这些 Provider 组成一个「栈」,上层(外壳、领域)通过它们获得能力。内核层在最底,不依赖领域。

五、外壳层(shell):应用骨架

外壳层是前端的「顶层骨架」:

• Bootstrap:应用启动流程
• 路由:页面路由
• 命令面板:快捷命令入口
• 菜单:应用菜单
• 启动状态:加载、错误等状态
• 深链处理:Connect Link 等(第 11 章)

外壳层在顶层,可以 import 一切(它是协调者,不是被依赖的)。它把内核的 Provider 组装起来,挂载路由,渲染领域模块。

六、领域层(domains):业务模块

领域层是具体的业务模块,每个是一个内聚的功能区:

领域模块通过内核的 Provider 访问能力(调服务端、用平台),不直接 import 框架无关层的实现(走 Provider 抽象)。

七、依赖规则(零环)

三层的依赖规则严格:

app(框架无关) ◄─ 被 kernel 引用
   │
kernel ◄─ 被 domains 引用(但不准 import domain)
   │
shell(顶层) ──► 可 import 一切
domains ──► 可 import kernel/infra/design-system
infra ◄─ 被 kernel/domains 引用
​

关键规则:

• leaf 模块不 import(最底)
• kernel/infra 不准 import domain(下层不依赖上层业务)
• shell 在最顶,可 import 一切
• app/i18n 不准 import react-app(框架无关)

这套规则用 madge 验证零环(没有循环依赖)。零循环让依赖图清爽,改一处不会牵出无限连锁。

八、为什么这样分层

这套分层的好处:

• 职责清晰:每层管一类事(app 管逻辑、kernel 管能力、shell 管骨架、domains 管业务)。
• 可测试:框架无关层没 react,纯逻辑好测;Provider 可 mock。
• 可演进:加新领域不影响 kernel;换 UI 框架理论上只动 react-app,app 不变。
• 零环:循环依赖是大型项目噩梦,零环保证清爽。

九、本节要点回顾

1. 三层 + 框架无关层:app(纯逻辑)/ kernel(Provider)/ shell(骨架)/ domains(业务)。
2. app 禁止 import react:逻辑与 UI 严格分离,madge 强制检查。
3. kernel 是 Provider 栈:平台/服务端/SDK/同步/偏好/通知。
4. shell 是顶层骨架:Bootstrap/路由/命令面板/菜单,可 import 一切。
5. domains 是业务模块:session/workspace/settings 等,通过 Provider 访问能力。
6. 依赖规则严格零环:leaf 不 import、kernel 不 import domain、shell 最顶。
7. 好处:职责清晰/可测/可演进/零环清爽。

分层讲清了,下一节讲最关键的 Provider——Platform 抽象。