粗粒度功能模块划分的两个维度

完成[[获取功能树的三种途径与多种呈现形式]]和[[评审功能树辨别真假与两条判断标准]]两步之后，才真正进入划分功能模块本身的技能环节——架构师要能与需求人员打交道、能评价拿到的需求，这本身就是架构岗位应有的技能，也是架构师作为”通才”的一个例证。粗粒度功能模块划分要同时处理两个维度。一方面，业务上紧密相关的一组功能，在实现上常会涉及相同的函数、类、数据结构，因此应该把”这组功能”映射到一个”功能模块”，这样有利于设计的高聚合、松耦合，也有利于程序小组之间的分工——这正是[[从功能组到功能模块的核心原理]]的直接应用。另一方面，有一些公共服务（比如报错处理、Log日志、安全验证）会同时支持多组功能的实现，它们不专属于任何一个”功能模块”，不应该被强行塞进某个业务功能模块里，而应该进行独立的模块化，放入相应的”通用模块”或”通用机制”中。这两个维度合起来构成了粗粒度功能模块划分的完整框架：先按业务紧密度把功能聚合成模块（纵向切分），再把横跨多个模块的公共服务单独抽出来（横向抽取）——如果只做第一步而忽略第二步，公共服务代码就会在多个功能模块里被重复实现，这正是很多系统”各小组有重复代码”这个常见毛病的根源之一。