业务模块划分结构不等于总体架构

不论是电子、军工、系统控制等领域常说的”总体架构”“总体设计”，还是行业应用、商业软件领域常说的”总体架构”“设计方案”，都不等于单纯的”功能子系统划分”——设计总体架构时最常见的陷阱，就是划分完功能子系统就”了事儿”了。把类似[[粗粒度功能模块划分的两个维度]]产出的”业务模块划分结构”直接当成”总体架构”，会带来三大问题：后续研发任务不明确、细粒度功能上有重叠、代码级的重复在所难免。真正到位的总体架构方案，必须在业务模块划分结构之外，再补充一份”可交付的顶级子系统划分视图”——这正是第9章[[概念架构设计的一个决定四个选择]]中”1个决定”（如何划分顶级子系统）的具体落地：每个”顶级子系统”都应该是可交付的实体，而不是虚的抽象业务概念；具体而言，总体架构设计要把系统明确切分成后端系统、前端系统、底层嵌入式系统、中间件系统这些顶级子系统，并且把要开发的API、程序库、后端驱动程序、前端插件这些也当作特殊的顶级子系统尽早明确出来。书中用PM Suite案例对比这两种视图的差别：一边是”可交付的顶级子系统划分视图”，明确了后续系统研发任务的四个具体交付物——提供项目管理核心服务的后端系统、支持第三方二次开发的API、为用户提供的Web前端、为项目经理提供更高效计划管理体验的客户端；另一边只是表示”需求范围”的”业务域结构框图”（常被称为”业务模块图”）——后者说明的是”这个系统覆盖哪些业务领域”，前者说明的是”这个系统最终要交付出哪些实体、由哪些团队各自负责开发”，两种视图都有用，但只有前者才能真正支撑起后续的工作量估算、成本估算和并行化研发活动的开展。

结构图：

flowchart LR
    subgraph 业务视角["业务域结构框图（业务模块图）"]
        A["描述：这个系统覆盖哪些业务领域"]
    end
    subgraph 交付视角["可交付的顶级子系统划分视图"]
        B["后端系统"]
        C["API（支持二次开发）"]
        D["Web前端"]
        E["客户端"]
    end
    业务视角 -.->|"仅有此视图不足以支撑\n工作量/成本估算与并行研发"| 交付视角