我所在的项目在公司本身是以组件化开发著称，而我本身负责项目的组件集成，所以书中很多的观点可以说深有体会(本想说不谋而合的，哈哈)。

组件的定义

    作者认为组件是软件的部署单元，是整个软件系统在部署过程中可以独立完成部署的最小实体。比如，对于Java应用程序而言，Jar包就是组件；Ruby中的组件则是Gem文件；Python中的Egg或Wheel文件以及.Net下的DLL文件。

    当然，这里的jar包应该是把依赖的其它jar包等打包到自己的jar中（比如通过maven的maven-shade-plugin来实现），这样出来的jar包就是独立可部署的单元了。在实际的大项目中，每个jar包都只会打包自己的类，不会去包含依赖的jar包，否则底层jar包就会被多处包含，造成软件体积变大。单体程序如此，微服务架构也有类似的问题，虽然微服务的容器运行体积不会变大，但是我们在操作的时候会把公共的SDK打包为一个基础镜像，供上层组件制作应用镜像的时候进行依赖。所以一个jar包常常不能独立部署，甚至我们常规定义的组件也不能独立部署，而是提供一个独立的功能。

好的组件要求是高内聚，底耦合，那么组件的聚合与耦合该遵循什么原则呢？

组件聚合

作者就组件聚合，也就是哪些类应该被组合到一个组件，提出了三个原则：

REP（复用/发布等同原则）：软件复用的最小粒度应该等同于其发布的最小粒度。

CCP（共同闭包原则）：将会同时修改，并且为相同目的而修改的类放到同一个组件；不会同时修改，并且目的不同的类放到不同的组件

CRP（共同复用原则）：不要强迫一个组件的用户依赖他们不需要的东西

精华汇聚成如下的组件聚合张力图，与CAP定理（指的是在一个分布式系统中，Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性)，三者不可兼得）差不多，一个系统中，无法完全兼顾三个原则，关注某两个原则越多，对第三个原则损失也就越多。

组件聚合张力图

    我当前所在项目明显是更多注重REP和CCP，牺牲了CRP原则，这样造成的一个后果就是，我们会有一个较为庞大的基础组件，但应用组件达到了最小化。当这个基础组件不如预料那样稳定，而会频繁修改，就会造成所有应用组件都会需要重新编译、验证。当还频繁出现不兼容变更，影响就会更大些了，也就出现张力图最上面的“太多不必要的发布”的问题，这对我们持续集成的要求就非常高了。

组件耦合

    组件之间不可避免会出现依赖关系，依赖关系不同组件之间集合为一个大系统的必备条件。

    我负责的上一个项目，使用ant构建，很多组件耦合在一起进行编译，当某个组件依赖另一个组件编译的时候，直接采用拷贝或写死依赖路径的方法。这样每个组件完全没法独立编译，开发人员本地编译，通常需要对整个软件进行全量编译，完成后才可以对自己的代码进行修改编译。开发人员通常不会及时更新别的组件代码，也不会经常进行全量编译，造成明明本地编译可以通过的代码，项目集成全量编译还是经常编译不过。

    后来为了进行组件化编译，引用ant+ivy的方式进行依赖解耦，花了很大代价才完成改造，使得组件独立构建成为可能。

    所以依赖本身不能说好或者不好，作者在这里也提出了三个原则：

ADP（Acyclic Dependencies Principle 无依赖环原则）：组件依赖关系图中不应该出现循环。

当前我们项目采用maven构建，nexus仓库进行制品管理，仓库的缓存造成同版本出现依赖循环也无法及时发现，这个在当前构建中需要通过切换版本号才会暴露出问题，而切版本一般都是临近版本发布集成时间点，这样经常会阻塞集成，且没有一个好的方法来提前发现。

SDP（Stable Dependencies Principle 稳定依赖原则）：依赖关系必须要指定更稳定的方向。

该原则的核心就是被依赖多的，如我们常说的SDK，基础组件，需要更多的保持稳定性。作者提出一个稳定性指标：出向依赖（Fan-out）/(出向依赖（Fan-out）+入向依赖（Fan-int）)，极端情况，Fan-out为0，即该组件完全不依赖其它组件，说明这个组件的稳定性指标高，反之，Fan-int为0，即完全没有组件依赖自己，那么组件稳定性指标差。

SAP（Stable Abstractions Principle 稳定抽象原则）：一个组件的抽象化程度应该与其稳定性保持一致

这里是对第二点指标的补充，也就是说，并不是说组件稳定性指标差就是不好，相反，稳定性指标差的组件，有更多的修改是可以接受的，反而稳定性指标高的组件，被频繁修改，反而是不可接受的，这会造成一系列依赖组件的修改。

稳定抽象原则