层、功能模块与细粒度模块的三层关系

有人习惯划分功能模块，有人习惯分层——[[模块划分的四种思路]]中这两种思路分别关注垂直维度切分和水平维度切分，两者并不矛盾。设计思维融合的关键是把层（Layer）、功能模块、细粒度模块这三个概念看清想透。功能模块是粗粒度的，一般对应一个功能组，最大的用途是基于功能模块进行开发小组分工。层也是粗粒度的（UI交互层封装人机交互、系统交互层封装硬件访问和外部系统交互、数据管理层封装DB/File/Flash存储），是一种有价值且流行的关注度分离手段。但无论功能模块划分还是分层，都还不够——模块划分设计需要进一步做到细粒度模块一级：一个细粒度模块必然位于架构的某一层中，同时一般也都会属于某个更大粒度的功能模块内，也就是说细粒度模块同时被”层”和”功能模块”两个维度定位。如果架构设计”止于功能模块划分”或”止于粗粒度分层”，就意味着设计不足、还要继续——比如每一层内部哪些”小模块”可以重用、哪些不能重用，功能模块内部不同”小模块”之间的调用关系是否合理，这些问题都需要细粒度模块层面才能回答，对未来增加功能或修改功能实现的影响很大。书中用一个综合应用的例子说明这种交叉划分的实际价值：一个采用水平分层架构的软件系统，同时也体现着报表功能模块、拓扑功能模块等垂直切分思想——拓扑功能模块业务逻辑复杂（图元的排列、连接、移动、覆盖、复制、删除涉及不同规则），适合用Martin Fowler归纳的领域模型架构模式来解决；报表功能模块业务逻辑相对简单（通过SQL语句从数据库提取数据、做统计查找计算就够用），适合用Martin Fowler归纳的事务脚本模式（换用领域模型模式反而是”自找麻烦”）。这个例子说明同一个系统里，不同的功能模块即便共用同一套分层骨架，内部具体采用哪种细粒度设计模式完全可以不同，要按各自业务复杂度的实际情况分别决定。

结构图：

flowchart TB
    A["细粒度模块"] -->|"位于某一层中"| B["层（Layer）\n水平切分，关注度分离"]
    A -->|"属于某个功能模块"| C["功能模块\n垂直切分，便于开发分工"]
    C -.->|"内部可采用不同细粒度设计模式\n如：领域模型模式（拓扑模块）\n事务脚本模式（报表模块）"| A