组件聚合张力图：三原则的竞争关系与随项目成熟度的动态平衡

[[REP复用发布等同原则软件复用的最小粒度应等同发布粒度]]、[[CCP共同闭包原则是SRP在组件层面的再度阐述]]、[[CRP共同复用原则的真正重点是不该放在一起的类]]三条原则彼此存在竞争关系：REP和CCP是黏合性原则，倾向于让组件变得更大（REP要求组件内容主题一致方便统一发布，CCP要求同一变更原因的类聚在一起方便集中部署）；CRP是排除性原则，倾向于让组件变得更小（避免用户依赖用不到的类）。软件架构师的任务，就是在这个三角张力区域里为当下的研发团队状态找一个合适的落点，并随时间不断调整——只关注REP和CRP、忽视CCP的架构师会发现，即使简单的变更也会波及许多组件；反过来只关注CCP和REP、忽视CRP的架构师，会制造出很多不必要的发布。这个平衡点不是一成不变的：项目早期研发速度比复用性更重要，CCP应该比REP更受重视，此时项目重心通常落在张力三角区域偏向”牺牲复用性”的一侧；随着项目逐渐成熟、越来越多其他项目开始依赖它，重心会逐渐向复用性一侧滑动。也就是说，组件结构的划分方式主要取决于项目所处的开发阶段和被使用的方式，而不是项目本身的功能——这也意味着当下适用的组件划分，明年很可能就不再适用，组件构成安排理应随项目重心的迁移而持续演化。

结构图：

flowchart TD
    REP[REP: 复用/发布等同<br/>黏合性,要求主题一致] ---|张力| CCP[CCP: 共同闭包<br/>黏合性,同一变更原因聚合]
    CCP ---|张力| CRP[CRP: 共同复用<br/>排除性,避免不必要依赖]
    CRP ---|张力| REP
    Early[项目早期: 重研发速度] -.重心偏CCP轻REP.-> REP
    Mature[项目成熟: 重复用性] -.重心向REP CRP一侧滑动.-> CCP