我是《架构整洁之道》(Clean Architecture) 中文版的技术审校者，在审校的过程当中略有感悟，所以希望通过撰写导读的方式分享给大家。
组件聚合
组件的定义
组件是软件部署的最小单元，是整个软件系统在部署过程中可以独立完成部署的最小实体。比如，对于Java应用程序而言，Jar包就是组件；Ruby中的组件则是Gem文件；Python中的Egg或Wheel文件以及.Net下的DLL文件。
上回我们说到，编程范式的本质是约束。子过程、类或函数是我们编程过程中的基本元素，所以说编程范式是程序的基础构件。如果将这些基本构件比作建筑里的泥沙石，那么程序中的组件就可以类比成砖头。砖头的工艺注重材料配比，组件也是如此，恰如其分的基础构件配比是组件稳定的基础。组件的内容配比较难定量，但是在实践上，仍然受到指导原则的约束。
软件工程中的约束三角
在软件工程中，我们会看到很多约束条件都能由三角形的方式体现出来。这是因为三角形除了具有稳定的特性以外，还能体现出一种张力。
软件开发中的各种三角
比如在敏捷项目管理中，我们常会听到时间，资源和成本的约束三角；在分布式计算中，著名的CAP（一致性，可用性和分区容错性）原理也是如此；还有区块链中的不可能三角（性能，安全和去中心化）。这些三角都在反映一种约束——不能完全同时满足，需要权衡。
组件聚合张力图
组件的内容配比，最终反映在组件的实践上就是基本构件的拆与合。鲍勃大叔给出了三个拆合的指导原则：REP（复用/发布等同原则），CCP（共同闭包原则）和CRP（共同复用原则）。
组件聚合张力图
- REP（复用/发布等同原则）：软件复用的最小粒度应该等同于其发布的最小粒度
- CCP（共同闭包原则）：将同时修改，目的相同的类放到同一个组件；不会同时修改，目的不同的类放到不同的组件
- CRP（共同复用原则）：不要强迫一个组件的用户依赖他们不需要的东西
这些原则乍看上去是全新的理念，细细品来又好像“新瓶装旧酒”的老把戏。CCP不就是SRP（单一职能原则）？CRP不就是ISP（接口隔离原则）？REP，等等，这是不言自明的公理呀！难怪有些架构师朋友说，鲍勃大叔老了，又拿着SOLID那一套概念出来忽悠骗钱。
其实，不妨换个思路想想，通常当谈论SOLID、高内聚低耦合、稳定依赖、稳定抽象系列原则的时候，我们是处于软件系统生命周期的哪一环？不出意外，大家都是从编写源代码，即开发（Development）的角度出发的。但是，我们又清晰地了解，软件系统的生命周期其实还包含除开发之外的部署、发布，运行和维护环节。那么问题来了，在这些环节里，哪些指导原则是适用的呢？
在跳脱了开发的思维桎梏之后，我们通过两种手段分析下这三条原则。
分开看
REP原则阐述了一个简单的道理：软件复用是基本要求。在追求软件复用的过程中，逐步形成了标准的发布流程，如：版本号（语义化版本），发布时间，变更内容等。这要求组件中所包含的模块和类都必须同时可发布，而可发布的深层含义既是对用户的承诺，也是对作者的约束。组件是否向后兼容？是否包含破坏性的变更？升级的注意事项？
CCP原则是指尽量把变更频率相同的模块和类放到同一个组件当中。这样做的好处是，当相关功能更新时，我们可以把源代码的变更局限在某一个组件当中，而不需要横跨多个组件，从而减少了部署，验证和发布的次数。概括来说，这是局部化影响的优势。CCP和OCP（开闭原则）中强调的“闭包”也有关联，所谓封装可变因素就是形成闭包的过程，CCP要求将同一时间变更的点聚合起来，达到闭包的效果。
CRP原则是说组件和组件之间的依赖应该达成一种默契——如果不需要完全使用某个组件中所有的模块和类，那么就不要依赖它。这看上去不太可能，但是有一点意义，它指导我们：不是紧密相连的模块和类不应该被放到同一个组件里。因为我们知道一旦某个组件变更升级之后，依赖它的组件往往也会被动的变更升级，即便是和自己那些无关的变更也是如此。而每次变更都意味着重新编译，部署验证和发布。
合起看
REP原则说明软件复用是基础，复用是通过发布流程规范的。在复用和发布的上下文中，CCP原则为了便于后期维护，需要尽可能地将变更频率相同的模块和类放到相同的复用单元——组件中；CRP原则为了避免频繁发布，应该将每个组件分割的足够小，减少无关变更导致依赖链条的连锁发布反应。
如果我们只兼顾REP和CCP原则，那么就可能由于连锁发布反应，出现很多不必要的发布；如果只兼顾REP和CRP原则，那么就可能因为实现一个功能需要横跨多个组件修改，造成过多的组件变更；如果只兼顾CCP和CRP，那我们可能就忘记了复用这档子事儿，这在先前我们批判鲍勃大叔的时候已经体现出来了。
小结
软件系统的生命周期里处处充斥着约束条件，每多一个环节往往就会多一种矛盾，进而衍生出多个方向的约束。组件聚合张力图反映的是发布和开发之间的矛盾，需要尽量遵循REP，CCP和CRP原则，满足其约束，才能减少变更成本。
组件构建过程中，除了聚合原则，还有耦合原则——描述的是组件的依赖关系。聚合原则告诉我们的是软件系统中的最小元素，耦合原则说的是元素之间的关系，当这两者和系统的功能结合到一起，就构成一个运行着的系统[1]。系统是逐渐演化出来，即便我们熟知REP，CCP和CRP原则，也没有办法说，在系统构建之初，遵循这些原则就能画出完美的组件结构图。这便是“自顶而下”的设计不靠谱的基本解释。
“自定而下”的设计不靠谱还有更深层次的原因。本书的第14章“组件耦合”会有答案，且听下回分解。
