【软件架构设计方法论（14）】粗粒度功能模块划分：从功能树到架构设计

开头引入

功能模块划分是架构师的"核心技能"和"基本职责"——通过将系统分解为功能模块，实现模块内高内聚、模块间松耦合，让大型系统变得可管理。

正如Hassan Gomaa所说：“要成功管理大型软件系统的固有复杂性，必须提供一种将系统分解为子系统的方法…分解并仔细定义子系统之间的接口后，每个子系统可以独立设计。”(本质上是控制复杂度)

本文通过功能树方法和酒店管理系统实战案例，帮你掌握"从需求到设计"的模块划分方法。

 

核心知识点铺垫

知识点1：功能树——需求分析的"功能清单"

通俗理解：功能树像一张"功能清单树"，把系统要做什么功能，按照"功能类别→功能组→功能项"的层次结构组织起来，让你一目了然地看到系统的所有功能。

核心作用：功能树是需求分析的框架工具，帮助分析师逐层选择和确定系统必须拥有的功能（Function）和特性（Feature），是需求分析阶段的产出物。

核心要点的3个要点：

要点1：功能树的本质

• 本质：功能树是功能分解结构，描述的是"问题域"（系统要解决什么问题），属于需求分析层。它回答的是"系统要做什么"，而不是"系统怎么做"。
• **为什么需要功能树？**因为大型系统的功能往往很多，如果不组织成树状结构，需求分析会变得混乱。功能树通过层次化的方式，让分析师能够系统化地梳理功能，避免遗漏。
• 深层原理：功能树体现了"分而治之"的思想——将复杂的系统功能分解为多个层次，每个层次关注不同粒度的功能，从而降低需求分析的复杂度。

要点2：功能树 vs 功能模块结构图

• 功能树：是功能分解结构，描述问题域，属于需求分析层，是架构师从上游（需求分析师）获得的。
• 功能模块结构图：是结构分解结果，描述解决方案，属于设计层，是架构师自己设计的。
• **为什么必须区分？**因为软件架构设计的难点在于"架起从现实世界（问题域）到计算机世界（解决方案）的桥梁"。需求分析阶段关注"问题是什么"（功能树），架构设计阶段关注"怎么解决"（功能模块结构图）。如果混淆两者，会导致用需求分析的思维做架构设计，无法正确划分模块。

要点3：功能树的结构

• 层次结构：功能树按照"功能类别→功能组→功能项"的层次组织，形成树状结构。
• **为什么是树状结构？**因为功能之间存在"隶属关系"和"支撑关系"——上层功能是下层的概括，下层功能是上层的细化。树状结构能够清晰地表达这种层次关系。
• 实际例子：呼叫中心系统的功能树，顶层是"自动服务"、“人工服务”、“其他功能"等功能类别，每个类别下又有功能组（如"自动语音服务”），功能组下又有功能项（如"最新公告"、“用户自助管理”）。

功能树示例（呼叫中心系统）：

呼叫中心系统
├── 自动服务
│   ├── 自动语音服务
│   │   ├── 最新公告
│   │   ├── 用户自助管理
│   │   └── 用户留言
│   ├── 自动传真服务
│   │   └── 发送传真服务
│   │       ├── 在线传真
│   │       └── 离线传真
│   └── 接受传真服务
├── 人工服务
│   ├── 被动服务
│   │   ├── 技术咨询
│   │   ├── 服务与产品购买
│   │   └── 投诉建议
│   └── 主动服务
│       ├── 电话营销
│       └── 满意度调查
└── 其他功能
    ├── 系统管理
    └── 知识管理

知识点2：功能分解≠结构分解——区分问题域和解决方案

通俗理解：功能分解像"列购物清单"（要买什么），结构分解像"规划购物路线"（怎么去买）。两者完全不同，但很多人容易混淆。

核心作用：理解功能分解和结构分解的区别，是正确进行模块划分的前提。功能分解关注"做什么"（问题域），结构分解关注"怎么做"（解决方案）。

核心要点的3个要点：

要点1：本质区别

• 功能分解：将系统功能按照业务逻辑进行分解，形成功能树。它描述的是"问题域"——系统要解决什么问题，要提供什么功能。
• 结构分解：将系统结构按照技术实现进行分解，形成功能模块结构图。它描述的是"解决方案"——系统怎么实现这些功能，有哪些模块。
• 为什么必须区分？ 因为软件架构设计是"从问题域到解决方案的桥梁"。需求分析阶段（功能分解）关注"问题是什么"，架构设计阶段（结构分解）关注"怎么解决"。如果混淆两者，会导致用需求分析的思维做架构设计，无法正确划分模块。

要点2：为什么容易混淆？

• 表面相似：功能树和功能模块结构图都是树状结构，都涉及"分解"，容易让人以为是一回事。
• 深层原因：很多人没有理解"问题域"和"解决方案"的区别，认为"功能"就是"模块"，导致直接用功能树作为模块划分的依据。
• 实际危害：如果直接用功能树划分模块，会导致模块划分（todo：待实践体会）不合理——模块之间耦合度高，模块内聚度低，无法实现"高内聚、松耦合"的目标。

问题域 vs 解决方案示意图：

需求
  ↓
问题领域（功能树：功能分解）
  ↓
软件架构（转换桥梁）
  ↓
解决方案（功能模块结构图：结构分解）
  ↓
软件系统

关键区别：

• 功能树（问题域）：描述"系统要做什么"，是功能分解结构
• 功能模块结构图（解决方案）：描述"系统怎么做"，是结构分解结果

要点3：如何正确理解？

• 功能树（功能分解）：描述"系统要做什么"，是需求分析的产出物，架构师从上游获得。
• 功能模块结构图（结构分解）：描述"系统怎么做"，是架构设计的产出物，架构师自己设计。
• 转换过程：从功能树到功能模块结构图，需要架构师进行"设计转换"——分析功能之间的实现关系，将业务上紧密相关的功能组映射到功能模块，实现"高内聚、松耦合"。

 

知识点3：从功能组到功能模块——高内聚、松耦合的核心原理

通俗理解：像"把相关的工具放在同一个工具箱"——业务上紧密相关的功能，实现时往往涉及相同的类和数据，应该放在同一个模块中。

核心作用：将"功能组"映射到"功能模块"，是实现模块内高内聚、模块间松耦合的核心方法。通过分析功能的实现关系，将业务上紧密相关的功能组划分到同一个功能模块。

核心要点的3个要点：

要点1：核心原理

• 原理：业务上紧密相关的一组功能，实现时往往涉及相似的类、相似的数据结构。因此，将"功能组"映射到"功能模块"，可以实现模块内的高内聚（功能相关、实现相关）、模块间的松耦合（不同模块的实现相对独立）。
• 为什么这样设计？ 因为功能的实现不是由单个类完成的，而是由多个相互协作的软件元素一起完成的。如果业务上紧密相关的功能涉及相同的软件元素，将它们放在同一个模块中，可以让这些元素共享，减少重复代码，提高内聚度。
• 深层原因：软件设计的核心目标是"高内聚、松耦合"。高内聚意味着模块内的元素紧密相关，松耦合意味着模块间的依赖关系简单。通过将功能组映射到功能模块，可以实现这个目标。

要点2：映射关系

• 功能组：功能树中业务上紧密相关的功能集合（如"办理预定"、“办理入住”、"办理退房"都是酒店前台服务相关的功能）。
• 功能模块：架构设计中实现这些功能的模块（如"宾客服务"模块）。
• 映射逻辑：分析功能的实现关系，如果一组功能涉及相同的类、相似的数据结构，就将它们映射到同一个功能模块。
• 为什么这样映射？ 因为这样可以实现代码复用（相同的类可以被多个功能共享）、降低耦合（不同模块的实现相对独立）、便于分工（一个模块可以分配给一个开发小组）。

要点3：通用模块的分离

• 通用模块：一些公共服务（如错误报告、日志记录、安全验证）同时支持多组功能的实现，不属于任何单一"功能模块"。
• 为什么需要分离？ 因为这些公共服务是多个功能模块都需要的基础设施，如果放在某个功能模块中，会导致其他模块依赖这个模块，增加耦合度。
• 如何分离？ 将这些公共服务独立模块化，放入对应的"通用模块"或"通用机制"中，让所有功能模块都可以使用，但不依赖特定的功能模块。

功能模块划分示意图：

酒店管理系统
├── 功能模块（4个）
│   ├── 资产管理模块
│   ├── 宾客服务模块
│   ├── 人员考核模块
│   └── 系统维护模块
└── 通用模块（1个）
    └── 角色与权限管理框架

从功能组到功能模块的映射：

功能树（问题域）             功能模块结构图（解决方案）
─────────────────          ──────────────────────
宾客服务（功能组）    →      宾客服务模块
├── 办理预定                ├── Reservation UI
├── 办理入住                ├── Checkin UI
└── 办理退房                ├── Checkout UI
                            ├── ServiceManager
                            ├── PayManager
                            ├── Reservation
                            └── Room

知识点4：功能树的获得与评审——确保需求完整准确

通俗理解：功能树像"需求清单"，需要从各种渠道收集，然后检查是否完整、是否准确。

核心作用：获得功能树是模块划分的第一步，评审功能树是确保需求完整准确的关键。只有获得准确完整的功能树，才能正确划分功能模块。

核心要点的3个要点：

要点1：如何获得功能树？

• 三种方式：获取文档、沟通交流、分析产品。
• 获取文档：《软件需求规格说明书（SRS）》是最可能出现功能树的地方，因为SRS会系统化地描述功能，其"章-节-小节"结构往往就体现了功能树。更上游的文档如《愿景文档》《方案建议书》也可能包含功能树。
• 沟通交流：与业务人员、需求分析师沟通，收集功能信息，然后自己组织成功能树。
• 分析产品：分析本公司或竞争对手的产品（包括文档、市场材料、UI界面），提炼功能树。
• **为什么需要多种方式？**因为功能树可能出现在不同的地方，单一渠道可能不完整。通过多种方式收集，可以确保功能树的完整性。

要点2：如何识别真正的功能树？

• 功能树 vs 页面流转图：功能树是功能分解结构，描述"系统要做什么"；页面流转图是页面跳转关系，描述"用户怎么操作"。页面流转图不能作为功能树，因为它描述的是交互流程，不是功能分解。
• 判断标准：功能树的上层节点是更高层次的"功能组"，下层节点是"子功能"，上下层节点之间是"隶属关系"和"支撑关系"。页面流转图描述的是"页面跳转关系"，不是功能分解关系。
• **为什么必须区分？**因为如果用页面流转图作为功能树，会导致模块划分错误——按照页面跳转关系划分模块，无法实现"高内聚、松耦合"。

功能树 vs 页面流转图对比：

❌ 页面流转图（不是功能树）：

系统登录
├── 数据编辑
│   ├── 第一个
│   ├── 前一个
│   ├── 下一个
│   └── 添加/编辑/删除
├── 数据查询
│   ├── 搜索
│   └── 全部
└── 系统维护
    ├── 系统数据转换
    └── 修改系统密码

说明：这是页面跳转关系，不是功能分解

✅ 功能树（真正的功能树）：

设备管理系统
├── 设备管理（功能组）
│   ├── 录入设备记录（功能项）
│   ├── 维护设备记录（功能项）
│   └── 维护维修记录（功能项）
├── 系统管理（功能组）
│   ├── 组织结构管理（功能项）
│   └── 设备类别管理（功能项）
└── 设备统计查询（功能组）
    ├── 维修统计查询（功能项）
    └── 调拨统计查询（功能项）

说明：这是功能分解结构，描述"系统要做什么"

要点3：如何评审功能树？

• 两个标准：用户导向、全面覆盖。
• 用户导向：功能树应该反映用户价值，从用户视角组织功能，而不是从技术视角。如果功能树从技术视角组织（如"金额计算"、“按键处理”），说明没有理解用户需求。
• 全面覆盖：功能树应该全面覆盖系统功能，不能遗漏重要功能。如果功能树遗漏了关键功能（如"故障报警"、“现金箱控制”），说明需求分析不完整。
• **为什么需要评审？**因为功能树是模块划分的基础，如果功能树不准确、不完整，后续的模块划分就会出错。评审功能树可以及早发现需求问题，避免设计阶段的返工。

差的功能树示例（自动售货机管理系统）：

自动售货机管理系统
├── 金额计算
│   ├── 金额累加
│   ├── 清除现有金额
│   └── 计算退币金额
└── 按键处理
    ├── 按键按下处理
    └── 点亮可售货等待

问题：

• ❌ 从技术视角组织（“金额计算”、“按键处理”），不是用户视角
• ❌ 遗漏重要功能：故障报警、现金箱控制、加载人员功能等
• ❌ 无法指导模块划分：哪些功能应该放在哪个模块？

好的功能树应该：

• ✅ 从用户视角组织（如"售货服务"、“设备管理”、“故障处理”）
• ✅ 全面覆盖系统功能，不遗漏关键功能
• ✅ 能够指导模块划分

 

实战场景串联

场景背景

项目：某酒店开发酒店管理系统，需要支持前台办理预定、办理入住、办理退房，经理进行人员考核，管理员进行系统维护等功能。

需求文档：提供了用例图，显示了不同角色的功能需求：

• 前台：办理预定、办理入住、收取押金、办理退房
• 经理：人员考核相关功能
• 管理员：系统维护相关功能

问题：如何将这些功能需求转换为功能模块划分？如何实现"高内聚、松耦合"？

第一步：获得功能树

目标：从需求文档中获得功能树，明确系统要提供哪些功能。

核心操作要点：

要点1：从用例图提取功能

• 分析用例图，识别所有功能项：前台功能（办理预定、办理入住、收取押金、办理退房）、经理功能（人员考核）、管理员功能（系统维护）。
• **为什么从用例图提取？**因为用例图描述了系统要提供的功能，是功能树的重要来源。

要点2：组织成功能树结构

• 按照"功能类别→功能组→功能项"的层次组织功能。
• 对于酒店管理系统，可以组织为：
  • 宾客服务（功能类别）
    • 预定服务（功能组）：办理预定（功能项）
    • 入住服务（功能组）：办理入住、收取押金（功能项）
    • 退房服务（功能组）：办理退房（功能项）
  • 人员考核（功能类别）：人员考核相关功能（功能组）
  • 系统维护（功能类别）：系统维护相关功能（功能组）
  • 资产管理（功能类别）：资产管理相关功能（功能组）

要点3：补充通用功能

• 识别所有角色都需要的基础功能：登录、退出、修改密码。
• 这些功能不属于任何单一功能类别，应该作为通用功能处理。

为什么这么设计？

• 从用例图提取：因为用例图是需求分析的标准产出物，描述了系统要提供的功能，是功能树的重要来源。
• 组织成树状结构：因为功能之间存在层次关系，树状结构能够清晰地表达这种关系，便于后续的模块划分。
• 补充通用功能：因为有些功能是多个角色都需要的基础功能，如果不单独识别，会导致后续模块划分时不知道如何处理。

第二步：评审功能树

目标：确保功能树用户导向、全面覆盖，为模块划分提供准确的基础。

核心操作要点：

要点1：检查用户导向

• 检查功能树是否从用户视角组织功能，而不是从技术视角。
• 好的功能树：从业务视角组织（如"宾客服务"、“人员考核”），用户能够理解。
• 差的功能树：从技术视角组织（如"金额计算"、“按键处理”），用户无法理解。
• **为什么必须用户导向？**因为功能树是需求分析的产出物，应该反映用户价值。如果从技术视角组织，说明没有理解用户需求，后续的模块划分也会出错。

要点2：检查全面覆盖

• 检查功能树是否覆盖了所有重要功能，没有遗漏。
• 对于酒店管理系统，需要检查：是否遗漏了"故障报警"、"现金箱控制"等关键功能？是否遗漏了"加载人员"的功能？是否遗漏了"资产管理"相关功能？
• **为什么必须全面覆盖？**因为功能树是模块划分的基础，如果遗漏了重要功能，后续的模块划分就会不完整，导致系统功能缺失。

要点3：区分功能树和页面流转图

• 确保获得的是功能树（功能分解结构），而不是页面流转图（页面跳转关系）。
• 功能树：描述"系统要做什么"，按照功能类别组织。
• 页面流转图：描述"用户怎么操作"，按照页面跳转关系组织。
• **为什么必须区分？**因为页面流转图不能作为功能树，用它划分模块会导致模块划分错误。

为什么这么设计？

• 检查用户导向：因为功能树应该反映用户价值，从用户视角组织功能。如果从技术视角组织，说明需求分析有问题。
• 检查全面覆盖：因为功能树是模块划分的基础，如果遗漏了重要功能，后续的模块划分就会不完整。
• 区分功能树和页面流转图：因为两者描述的内容不同，混淆会导致模块划分错误。

第三步：从功能组到功能模块划分

目标：将功能树中的功能组映射到功能模块，实现"高内聚、松耦合"。

核心操作要点：

要点1：分析功能的实现关系

• 分析每个功能的实现涉及哪些类、哪些数据结构。
• 对于酒店管理系统：
  • “办理预定”、“办理入住”、"办理退房"这三个功能，都涉及Room（房间）和Reservation（预定）等类。
  • PayManager（支付管理）和PrepayManager（预付费管理）职责相近、实现相似（都调用Finance Proxy）。
  • CheckinManager（入住管理）和CheckoutManager（退房管理）也以类似方式处理房间（Room）状态。
• **为什么分析实现关系？**因为功能的实现不是由单个类完成的，而是由多个相互协作的软件元素一起完成的。如果业务上紧密相关的功能涉及相同的软件元素，应该将它们放在同一个模块中。

要点2：将功能组映射到功能模块

• 将业务上紧密相关的功能组映射到同一个功能模块。
• 对于酒店管理系统：
  • “办理预定”、“办理入住”、"办理退房"这些功能都涉及房间管理和预定管理，可以共享ServiceManager、PayManager、Reservation等程序实现，因此映射到"宾客服务"功能模块。
  • "人员考核"相关功能映射到"人员考核"功能模块。
  • "系统维护"相关功能映射到"系统维护"功能模块。
  • "资产管理"相关功能映射到"资产管理"功能模块。
• **为什么这样映射？**因为这样可以实现模块内的高内聚（功能相关、实现相关）、模块间的松耦合（不同模块的实现相对独立），还便于将这组功能分配给一个程序小组负责开发。

要点3：分离通用模块

• 识别所有功能模块都需要的基础服务，将它们独立为通用模块。
• 对于酒店管理系统：
  • “登录”、“退出”、"修改密码"这些功能是所有角色都需要的基础功能，应该独立为"角色与权限管理"通用模块。
  • 错误报告、日志记录、安全验证等公共服务，也应该独立为通用模块或通用机制。
• **为什么需要分离？**因为这些公共服务是多个功能模块都需要的基础设施，如果放在某个功能模块中，会导致其他模块依赖这个模块，增加耦合度。独立为通用模块，让所有功能模块都可以使用，但不依赖特定的功能模块。

为什么这么设计？

• 分析实现关系：因为功能的实现涉及多个软件元素，只有分析实现关系，才能知道哪些功能应该放在同一个模块中。
• 将功能组映射到功能模块：因为业务上紧密相关的功能，实现时往往涉及相同的软件元素，将它们放在同一个模块中，可以实现"高内聚、松耦合"。
• 分离通用模块：因为通用服务是多个功能模块都需要的基础设施，独立为通用模块可以降低耦合度，提高复用性。

第四步：验证模块划分结果

目标：验证模块划分是否实现了"高内聚、松耦合"的目标。

核心操作要点：

要点1：检查模块内聚度

• 检查每个功能模块内的功能是否业务相关、实现相关。
• 对于"宾客服务"模块，检查"办理预定"、“办理入住”、"办理退房"这些功能是否涉及相同的类（如Room、Reservation），是否可以共享实现（如ServiceManager、PayManager）。
• **为什么检查内聚度？**因为高内聚意味着模块内的元素紧密相关，如果模块内的功能不相关，说明模块划分不合理。

要点2：检查模块耦合度

• 检查不同功能模块之间的依赖关系是否简单。
• 对于酒店管理系统，检查"宾客服务"模块是否依赖"人员考核"模块？如果依赖，说明耦合度高，需要调整。
• **为什么检查耦合度？**因为松耦合意味着模块间的依赖关系简单，如果模块之间相互依赖，说明模块划分不合理。

要点3：检查通用模块

• 检查通用模块是否被所有功能模块使用，但不依赖特定的功能模块。
• 对于"角色与权限管理"通用模块，检查是否所有功能模块都可以使用，但不依赖特定的功能模块。
• **为什么检查通用模块？**因为通用模块应该被所有功能模块使用，但不应该依赖特定的功能模块，否则会增加耦合度。

为什么这么设计？

• 检查内聚度：因为高内聚是模块划分的目标，如果模块内的功能不相关，说明模块划分不合理。
• 检查耦合度：因为松耦合是模块划分的目标，如果模块之间相互依赖，说明模块划分不合理。
• 检查通用模块：因为通用模块应该降低耦合度，如果通用模块依赖特定的功能模块，说明设计不合理。

 

总结收尾

通用应用逻辑

功能模块划分的通用逻辑可以总结为：“获得功能树→评审功能树→分析实现关系→映射功能模块→分离通用模块→验证划分结果”。

通俗比喻：就像"整理工具箱"——先列出所有工具（获得功能树），检查工具是否齐全（评审功能树），分析哪些工具经常一起用（分析实现关系），把相关的工具放在同一个工具箱（映射功能模块），把通用工具单独放（分离通用模块），最后检查工具箱是否整理好了（验证划分结果）。

可落地的交付物

功能模块划分检查清单：

1. 功能树获得：

   • 从需求文档（SRS、愿景文档、方案建议书）中提取功能树
   • 与业务人员、需求分析师沟通，补充功能树
   • 分析产品（本公司或竞争对手），提炼功能树
   • 确保功能树是功能分解结构，不是页面流转图

2. 功能树评审：

   • 检查功能树是否用户导向（从用户视角组织功能）
   • 检查功能树是否全面覆盖（没有遗漏重要功能）
   • 区分功能树和页面流转图

3. 模块划分：

   • 分析功能的实现关系（涉及哪些类、哪些数据结构）
   • 将业务上紧密相关的功能组映射到功能模块
   • 分离通用模块（所有功能模块都需要的基础服务）

4. 验证结果：

   • 检查模块内聚度（模块内的功能是否业务相关、实现相关）
   • 检查模块耦合度（模块间的依赖关系是否简单）
   • 检查通用模块（是否被所有功能模块使用，但不依赖特定的功能模块）

最简操作模板：

功能模块划分三步走：
1. 获得功能树：从需求文档、沟通交流、分析产品中获得功能树
2. 评审功能树：检查用户导向、全面覆盖，区分功能树和页面流转图
3. 划分功能模块：分析实现关系→映射功能模块→分离通用模块→验证划分结果

---

记住：模块划分是架构师的"核心技能"和"基本职责"。通过功能树方法，从需求分析的功能分解，转换为架构设计的结构分解，实现"高内聚、松耦合"的目标，让大型系统变得可管理。