从功能组到功能模块的核心原理

[[功能分解不等于结构分解]]之后，架构师要真正完成从问题域到解决域的转换，最常用的手段是”从功能组到功能模块”——这条原理成立的前提是一个经验观察：每个具体功能都不是由单一类或函数实现的，而是由多个相互协作的软件元素一起完成的，而业务上紧密相关的一组功能，在实现上涉及的元素也往往紧密相关、甚至是同样的元素。书中用酒店管理系统举例：架构师设计了资产管理、宾客服务、人员考核、系统维护四个功能模块（外加一个角色与权限管理的通用模块），设计依据是分析发现”办理预定”“办理入住”“办理退房”这三个功能的实现都涉及Room和Reservation等相同的类，PayManager和PrepayManager职责相近（都调用FinanceProxy），CheckinManager和CheckoutManager也以类似方式处理房间状态——这些高度重叠的实现元素说明，这一组功能天然就该归到同一个功能模块里，共享ServiceManager、PayManager、Reservation等程序实现，而不是各自独立设计、各写各的。把功能组对应到大粒度功能模块，能同时实现模块内的高内聚和模块间的松耦合，还能自然地把这组相近功能分配给同一个程序小组开发——这三重收益（内聚、解耦、分工）说明”从功能组到功能模块”这条原理不是一种任意的划分习惯，而是顺应了软件实现本身的自然聚集规律，架构师做的是发现这种规律、而不是发明规律。