模块化是在管理变化与理解成本

模块把系统划分为可以分别理解、实现和分配责任的单元。好的模块化不以文件数量或服务数量衡量，而看一次变化能否局限在合理范围，以及使用者是否只需理解稳定契约而不必掌握内部细节。

模块围绕职责形成边界

模块应拥有明确职责和对外能力。内容发布模块可以负责状态转换和发布约束，调用者通过服务接口执行动作，而不直接修改状态字段。边界把相关规则放在一起，使内部实现可以在契约范围内演进。

按控制器、服务、数据访问分层有助于技术组织，但不一定形成完整业务模块。如果一个业务变化必须同时修改许多横向目录，职责仍然是分散的。模块边界需要同时观察业务概念和技术依赖。

内聚描述共同变化的程度

内聚高的模块包含因相同原因变化的内容。身份验证、令牌刷新和会话撤销彼此相关，把它们与地图渲染参数混在一起会增加理解和发布风险。仅因代码都使用日期函数而放入同一模块，则通常只是表面复用。

过大的模块会承载多个独立变化原因，过小的模块则让一个动作跨越大量接口。合适粒度取决于变化频率、团队所有权和部署要求，不能由固定代码行数决定。

耦合来自多种依赖

源码导入只是耦合的一种。共享数据库表、共同部署、消息顺序、配置键和隐含调用时序都可能让模块必须一起改变。两个服务代码上独立，却共同读写没有所有者的表，实际耦合可能比单体内部模块更强。

降低耦合不意味着取消所有联系。系统功能本来就需要协作，目标是让依赖显式、方向清楚、契约稳定，并避免调用者依赖实现细节。

信息隐藏保护容易变化的决策

模块可以隐藏存储结构、算法选择和第三方协议，把外部需要的语义留在接口中。若接口直接暴露数据库字段或供应商响应，内部替换就会扩散到调用方。信息隐藏的对象应是可能变化且不应由外部决定的设计决策。

抽象过度同样有代价。为了假想的未来变化增加多层接口，会使当前行为难以追踪。应优先保护已有证据支持的变化点，并通过决策记录说明边界理由。

用真实变更检验模块结构

可以选取近期需求或故障，追踪涉及的代码、数据、测试和团队。如果一个小规则修改跨越很多无关模块，可能存在职责泄漏；如果每次发布都必须协调大量独立模块，契约或部署边界可能不合理。

模块化的成果不仅是目录图，还包括拥有者、公开接口、依赖规则和验证方式。随着变化模式发展，模块边界也可调整，但调整必须有迁移路径，不能用一次大规模重写代替持续演进。

资料依据

• Carnegie Mellon University Software Engineering Institute：Software Architecture，https://www.sei.cmu.edu/software-architecture/
• Carnegie Mellon University Software Engineering Institute：Early Analysis of Software Architecture，https://www.sei.cmu.edu/library/early-analysis-of-software-architecture/