5.2 大型应用开发

5.2 大型应用开发：拆分与协作

大型 Angular 应用的挑战不在代码量而在协作：几十人并行修改时，模块边界、依赖方向、发布节奏都要显式管理。本节讲工作区级拆分（多应用 + 多库）、库的三种形态（域库/工具库/UI 库）、依赖规则防循环，以及团队级协作用到的共享策略——主线视角的落点：拆分粒度直接影响懒加载边界与检查范围，边界画在哪里，性能预算就守在哪里。

学习目标

1. 规划多团队工作区：应用工程与库工程的划分标准。
2. 区分域库、工具库、UI 库三种形态并提供者策略差异。
3. 用依赖方向规则与检查工具防循环依赖。
4. 制定跨团队的发布与版本同步策略。

一、工作区拆分蓝图

workspace/
├── projects/
│   ├── shop-app/            面向用户的应用
│   ├── admin-app/           管理后台应用
│   ├── feature-order/       域库：订单域全部页面与状态
│   ├── feature-report/      域库：报表域
│   ├── data-sdk/            工具库：仓储客户端与类型
│   └── ui-kit/              UI 库：品牌组件（4.1 节 CDK 自绘路线）
└── angular.json
​

划分标准按团队边界而非技术层次：一个业务域一个库，团队对库有完整所有权。域库内部仍遵循 5.1 节的三层（只是压缩在库内），对外只暴露公开的门面（入口文件导出清单）——库的公开 API 是团队契约，未导出的实现细节可以随时重构。

拆分时机也有讲究：不必在第一天就拆满六个工程。健康路径是"先单应用内分域目录，域目录稳定、接口收敛后再升格为库"——目录是零成本的试验田，库是有维护成本的正式契约。过早拆库的代价是边界画错：业务理解加深后要挪动库边界，牵动的发布与引用远比挪目录昂贵。判断信号有两个：域的公开接口半年未大改、第二个应用开始复制该域的代码，满足其一就值得升格。

二、三种库的提供者策略

// 域库：状态仓库 providedIn root（或按需提供）
@Injectable({ providedIn: 'root' })
export class OrderStore { /* 5.1 节实现 */ }

// 域库的路由级私有服务：用路由 providers 而不是 root（2.1 节边界）
export const ORDER_ROUTES: Routes = [
  {
    path: '',
    providers: [OrderWizardService],   // 向导状态只在订单路由树内存活
    children: [/* ... */]
  }
];

// UI 库：绝不 providedIn root——组件级 providers，避免污染宿主注入器
@Component({
  providers: [TooltipController],     // 每个组件实例私有
  /* ... */
})
export class TooltipComponent { /* ... */ }
​

提供者策略错位的代价随规模放大：UI 库把服务挂到 root，两个应用同时引入时全局单例被抢占；域库把路由状态挂 root，路由离开后状态残留、下次进入读到脏数据。原则一句话：共享半径与技术层次匹配——UI 最小、域库居中、应用最大。

三、依赖方向与防循环

依赖规则（配合 lint 工具强制）：
  shop-app / admin-app  →  feature-*  →  data-sdk
                          →  ui-kit    →  （cdk / common）
  禁止：feature-order → feature-report（域间禁止横向依赖）
  域间通信只允许两种：宿主应用编排（页面级组合）、共享 data-sdk 的类型与仓储
​

域间横向依赖是循环依赖的温床：订单库引报表库的类型，报表库反过来引订单库的状态，三周后没人敢动任何一边。合法的解耦方式是在 data-sdk 定义共享类型（两域都依赖它），或在宿主应用层做页面编排——域与域之间通过"共同的下层"或"共同的上层"对话，永不直接握手。

⚠️ 坑：懒加载边界（2.6 节）要沿库边界画。若订单库大量引用报表库，路由懒加载切分就失效——加载订单域必须连带拉报表域代码。性能边界与技术边界必须是同一条线，这是大型应用拆分最重要的隐性约束。

图：多团队工作区依赖全景

四、发布与版本同步策略

多库工作区的版本同步有两条常见路线。固定版本路线：所有库与应用同仓同版本号，一次发布全量对齐——简单粗暴，适合发布频率不高的后台系统；独立版本路线：各库各自发版，应用按需升级——灵活但要求公开 API 纪律严格，适合对外共享的组件库。中间态是多数团队的实际选择：域库跟随应用同节奏发布，只有 data-sdk 与 ui-kit 这类基础库走独立版本。无论哪条路线，破坏性变更必须走废弃周期：先标记废弃并给出迁移指引，保留两个版本周期后再移除——这与 4.3 节框架自身的演进哲学同构，大项目内部也该长着一样的节律。

五、案例：三团队并行开发的协约定

背景：电商平台三团队（用户端、订单域、基础平台）同仓开发，早期互相等发布、代码冲突频繁。
操作：按上图拆工作区；立三条铁律——域间禁横向依赖（lint 强制）、库公开 API 变更需使用方评审、基础库双周发布域库随时跟进。跨域通信的两个合法通道都用上：订单域与用户端通过 data-sdk 的共享类型对齐契约；订单页需要嵌报表片段时由用户端应用层编排两个域的组件。
结果：三团队发布节奏解耦，互相等待消失；一次报表域大重构对用户端零影响（公开 API 未变）。
解读：大型应用的协作成本主要来自隐性耦合——看不见的横向依赖、说不清的提供者范围。规则显式化加工具强制后，耦合变成契约，团队才能各自全速跑。
变式：团队再多时引入代码所有权的目录级配置（每库一个 OWNERS 类文件），评审请求自动路由到责任团队，避免"谁都改、没人管"的公地悲剧。

本节要点回顾

• 按团队边界拆库：一域一库，公开 API 即团队契约，内部三层压缩。
• 提供者半径匹配层次：UI 组件级、域库路由级或 root、应用级。
• 域间禁横向：通过共同下层或宿主编排对话，lint 强制防循环。
• 双边界同线：懒加载边界沿库边界，技术边界与性能边界重合。
• 主线上的一环：拆分粒度决定懒加载切分，也就决定首屏组件树与首轮检查范围。

下一节：常用模式的 Angular 化形态。