最近一直在读《Clean Architecture》这本书，书中对与软件设计与架构的阐述是非常深刻的。因此开了一篇专栏，来记录《Clean Architecture》书中一些优秀的架构设计理念，以及我对这些内容的思考。
一、什么是组件
组件是软件的部署单元，是整个软件系统在部署过程中可以独立完成部署的最小实体。多个组件可以组装成一个独立的可执行文件。
比如 Java 中的 jar 文件，.Net 中的 DLL 文件。
程序规模的墨菲定律：
程序规模会一直不断增长下去，直到把有限的编译和链接时间填满为止。
二、组件聚合的原则
REP：复用、发布等同原则
组件复用的最小粒度等同于其发布的最小粒度。
这是一个非常好理解的原则，毕竟如果你想要复用某个组件的话，就必须要用该组件发布的某一个版本。
毕竟，只有引入了版本，才能让使用方知道组件发布的时间，以及每次发布带来的变更。之后，使用方才能够根据发布所更新的内容来决定继续使用旧版本还是做升级。
CCP：共同闭包原则
我们应该将那些会同时修改，并且为相同目的而修改的类放到同一个组件中。
这其实是单一职责原则在组件层面上的描述，对于大部分应用来说，可维护性的重要性远远高于可复用性。如果我们必须要对一些代码进行变更，那么它们最好在同一个组件里。这样在测试和部署的时候都只需要对该组件进行操作就可以了。
CRP：共同复用原则
不要强迫一个组件的用户依赖他们不需要用的东西。
CRP 的作用不仅是告诉我们应该将那些模块放到一起，更重要的是告诉我们应该将哪些模块分开。因为每当一个组件引用了另一个组件时，就会增加一条依赖关系，而当引用的组件发生变更时，引用它的组件也得做相应的变更，这样可能会消耗大量的精力来做不必要的组件部署。
三、组件耦合的原则
1、组件之间不应该出现环形依赖，合理的组件耦合结构应该是一个有向无环图。
2、依赖关系必须要指向更稳定的方向。换句话说，越是需要频繁修改的组件，越需要依赖那些相对稳定的组件。
而像下面这种依赖关系，就会导致 Flexible 组件的变更会非常困难。
也正是如此，组件的稳定性应该和他抽象的程度是保持一致的，也就是说，组件越稳定，其抽象程度应该就越高。
四、衡量组件的稳定性与抽象化的标准
对于组件的稳定性和抽象化我们可以用 IA 图来衡量，I 是稳定性，数值越高稳定性越低。A 是抽象化程度，0 代表没有抽象类，1 代表只有抽象类。
也就是说，最稳定的，包含了所有抽象类的组件应该在左上角，而最不稳定的，最具体的组件，应该在右下角。
而图中画的两个区域——“痛苦区”和“无用区”，则是设计组件时必须要避免踏入的区域。
在痛苦区的组件，会有很高的稳定性和很具体的逻辑实现，这就意味着该组件很难进行改动和扩展，这不是一个好的设计。
在无用区的组件，会有一个很低的稳定性和很抽象的逻辑实现，这就意味着这个组件基本没有其他组件去依赖它，但它的逻辑还很抽象，这种组件根本没办法使用。