[架构之路-102]：《软件架构设计：程序员向架构师转型必备》-12-粗粒度“软件架构的功能模块”划分，架构师必备基础技能

第12章 粗粒度“功能模块”划分

备注：

（1）功能划分的基本原则：

• 高内聚、低耦合

• 每个子系统、子模块可以独立设计

（2）划分方法

• 功能化

• 水平切分

• 垂直切分

• 分层

• 接口

12.1 功能树

12.1.1 什么是功能树

• 同一层次的功能之间具有互补性、互斥性，不能相互包含或重叠。

• 功能树是一种逐步功能分解的展现。

12.1.2 功能分解（需求）≠结构分解（架构）

备注：

功能树：是用于描述需求的，是由需求工程师完成。

功能模块结构图：是用于描述软件 架构的，是由架构师完成的。

12.2 借助功能树（需求），划分粗粒度“功能模块”（架构）

12.2.1 核心原理：从“功能组”到“功能模块”

从需求层面的“功能组”到软件架构的“功能模块”，之间是有一个鸿沟，这个鸿沟就是业务领域的问题域到计算机领域的设计域。

把多个相似的、相关联的功能，组合成一个功能组，对功能组进行抽象、凝聚、汇总，就得到“功能模块”。

需求层面的“功能组”可以通过功能树表达，也可以通过用例图表达，如下图所示：

功能需求到功能模块的设计和映射是架构设计的关键，其内在的原理是：每个功能需求都是由多个相互协同的不同的软件元素完成的。

因此，架构设计的关键环节是：

（1）设计每个功能需要的软件元素（对象）

（2）对所有功能所需要的所有软件原始进行归类（高内聚），得到功能模块。

（3）某个功能模块可以被多个功能需求共享

（4）得到的功能模块就是架构设计中得到的功能组

在上图中，相类似的功能需求组，整合成一个架构上的功能模块，实现软件架构的高内聚、低耦合。

具体实施步骤如下：

12.2.2 第1步：获得功能树

12.2.3 第2步：评审功能树

功能需求的本质：为完成客户或用户的某一个目标，很显然，在上图中，金额计算和按键处理，都不属于功能需求，都不属于用户的某个目标，它属于实现步骤，是一个某个功能实现众多步骤的一部分。

12.2.4 第3步：粗粒度“功能模块”划分

至此，获得的功能需求，现在可以基于功能需求，进架构设计：划分“软件功能模块”。

12.3 实际应用（9）——对比MailProxy案例的4种模块划分设计

12.3.1 设计

12.3.2 设计的优点、缺点

12.4 实际应用（10）——做总体，要提交啥样的“子系统划分方案”

备注：

架构必须时代码结构的体现，是业务需要和软件代码之间的桥梁。

一方面，它要体现业务功能需求，另一方面，他要体现软件的框架，软件会基于该框架进一步的细化代码实现。

感悟：架构师是用户与程序员的桥梁

架构（架构师）：必须站在程序员的角度，它描述的是软件系统的架构需要，只有站在程序的角度，程序员才能知道如何基于架构实现软件系统。

需求（需求分析师）：必须站在用户的角度，它描述的用户对目标系统的业务需求，只有站在客户的角度，客户才能知道未来实现的软件系统是满足自己业务需求的。

架构师：一脚站在用户的角度，思考用户的需求；另一脚站在程序的角度，思考实现用户业务需要软件的架构。架构师利用自己的大脑中的知识、经验把用户的需求，转换成软件的架构，程序员根据软件的架构，用编程语言和代码实现软件系统。