功能分解不等于结构分解

架构设计中”功能模块分解”最常见的错误，是把”功能分解”和”结构分解”混为一谈——维基百科上”功能树可视化了功能之间的调用关系”这类说法就是这种混淆的典型例子。软件架构设计之所以难，是因为它是跨越现实世界（问题领域）到计算机世界（解决方案）之间鸿沟的一座桥：需求分析的意图是明确”问题领域”，把要解决的问题以”功能+质量+约束”的形式定义下来，但需求做得再细（哪怕用例规约详细描述了各种意外场景），也没有打破”系统是黑盒子”这一点；软件架构设计要完成的是从”面向问题”到”面向解决方案”的转换——切分结构、定义协作、选择技术，这已经进入了系统黑盒内部。因此除非是极其简单的系统，否则必须区分”功能树”和”功能模块结构图”，它们根本不是一回事：功能树是一种功能分解结构，功能模块结构图是对系统进行结构分解的结果；功能树刻画的是问题领域，功能模块结构图刻画的是解决方案；功能树属于需求分析层面，功能模块结构图属于设计层面；功能树是架构师从上游（如需求分析师）那里得到的，功能模块结构图则是架构师要亲自设计出来的。这个区分之所以重要，是因为如果架构师误以为”功能树就是模块结构图”，很容易把需求文档里的功能分类直接照搬当成模块划分方案，跳过了架构设计真正应该完成的那次”问题域到解决域”的转换工作。

结构图：

flowchart LR
    subgraph 问题领域["问题领域（需求分析层面）"]
        A["功能树\n功能分解结构\n从上游获得"]
    end
    subgraph 解决方案["解决方案（设计层面）"]
        B["功能模块结构图\n结构分解结果\n架构师亲自设计"]
    end
    A -->|"架构师完成\n问题域到解决域的转换"| B