最近经常听到“组件化开发”，那架构设计里，组件到底如何定义、设计和应用呢，今天我们一起来聊聊。
本文主要内容：
- 什么是组件？
- 如何设计组件？
- 如何用组件构建系统？
1、什么是组件？
组件是软件的部署单元，是整个软件系统在部署过程中可以独立完成部署的最小实体/最小单元。
具体的表现大概如下：
- 编译运行语言，组件是一组二进制文件的集合
Java中，组件是jar文件，又称jar包 Ruby中，组件是gem文件 .Net中，组件是DLL文件
- 解释运行语言，组件是一组源代码文件的集合
Python中，组件是一个可以import的Module PHP中，组件是可以是Redis、Kafka等操作类的封装
什么样的组件是好的组件？
根据组件的定义，组件是整个软件系统在部署过程中可以独立完成部署的最小单元。从部署的角度上来说，多个组件可以链接成独立的可执行文件，也可以最总成部署单元，而单个组件也可以动态加载的插件形式来独立部署。
不论采用哪种形式，好的组件都应该永远保持可以被独立部署的特性，同时意味着组件应该可以被单独开发。
人们为了“偷懒”，为了减少源码合并和编译耗费的时间，而想出的一种东西。可以模块化编译、部署。
2、如何设计组件？
如果说类似SOLID这些编码设计原则，是用于指导我们如何用砖砌墙和盖房间，那么组件构建原则就是用来指导我们如何将这些房间组合成房子的。
用类组合一个组件的专业术语叫做：组件聚合。
2.1 组件聚合遵循的3个基本原则：
- REP：复用/发布等同原则
- CCP：共同闭包原则
- CRP：共同复用原则
即用来决定什么样的类应该被组合成一个组件。
2.1.1 REP：复用/发布等同原则
软件复用的最小粒度应等同于其发布的最小粒度。直白地说，就是要复用一段代码就把它抽成组件。
该原则指导我们组件拆分的粒度。
2.1.2 CCP：共同闭包原则
为了相同目的而同时修改的类，应该放在同一个组件中。该原则指导我们组件拆分的粒度。
一个类不应该同时存在着多个变更原因，将所有可能会被一起修改的类（不论是在源码层面或者是抽象理念层有紧密关系的类）集中在一起，组成组件。由同一个原因引起的代码修改，最好在同一个组件中，如果分散在多个组件中，那么开发、提交、部署的成本都会上升。
CCP针对的就是可维护性。对大部分应用程序，可维护性的重要性要远远高于可复用性。
2.1.3 CRP：共同复用原则
不要强迫一个组件的用户依赖他们不需要的东西。
相信你一定有这种经历，集成了组件A，但组件A依赖了组件B、C。即使组件B、C 你完全用不到，也不得不集成进来。这是因为你只用到了组件A的部分能力，组件A中额外的能力带来了额外的依赖。如果遵循共同复用原则，你需要把A拆分，只保留你要用的部分。
2.2 三原则关系
REP、CCP、CRP 三个原则之间存在彼此竞争的关系，REP 和 CCP 是黏合性原则，它们会让组件变得更大，而 CRP 原则是排除性原则，它会让组件变小。
- 遵守REP、CCP 而忽略 CRP ，就会依赖了太多没有用到的组件和类，而这些组件或类的变动会导致你自己的组件进行太多不必要的发布；
- 遵守 REP 、CRP 而忽略 CCP，因为组件拆分的太细了，一个需求变更可能要改n个组件，带来的成本也是巨大的。
优秀的软件架构师需要而且能够在这三者之间进行平衡。
3、如何用组件构建系统？
3.1 组件依赖/结构图
组件依赖/结构图，不是顶层设计的功能模块图，不与顶层设计的功能模块对应，同时不是用来描述应用程序功能的。
它更像是应用程序在构建性与维护性方面的一张地图，重要目标是指导如何隔离频繁的变更，我们不希望那些频繁变更的组件影响到其他本来应该很稳定的组件。
3.2 组件耦合原则
三个组件耦合原则（基于组件依赖/结构图）：
- 无依赖环原则（ADP）
- 稳定依赖原则（SDP）
- 稳定抽象原则（SAP）
3.2.1 ADP：无依赖环原则
循环依赖中的组件在发布的过程中，都必须要集成另一个它依赖的组件，而环中的组件都互相依赖，不存在独立相对的组件。导致发布困难，如下图情况所示：
消除环依赖的方法，主要是组件依赖关系图中不应该出现环。
1）应用依赖反转原则
2）创建一个新的组件
3.2.2 SDP：稳定依赖原则
依赖必须要指向更稳定的方向。
这里组件的稳定性指的是它的变更成本，和它变更的频繁度没有直接的关联（变更的频繁程度与需求的稳定性更加相关）。影响组件的变更成本的因素有很多，比如组件的代码量大小、复杂度、清晰度等等，最最重要的因素是依赖它的组件数量，让组件难以修改的一个最直接的办法就是让很多其他组件依赖于它！
组件被依赖的越多，则改动影响面越大，改动则越需要慎重，则改动困难程度越高，即改动没有那么随意，则稳定性高。而没有被依赖的组件，则随意改，看心情都行，改动困难程度非常低，则稳定性差。
3.2.3 SAP：稳定抽象原则
一个组件的抽象化程度应该与其稳定性保持一致。
在一个软件系统中，总有些部分是不应该经常发生变更的，通常用于表现该系统的高阶架构设计及一些策略相关的高阶决策。为了防止高阶架构设计和高阶策略难以修改，通常抽象出稳定的接口、抽象类为单独的组件，让具体实现的组件依赖于接口组件，这样它的稳定性就不会影响它的扩展性。
耦合指标
通过 稳定性指标I 和 抽象化程度A 可以推导：D指标（稳定性 I 与其抽象化程度 A 之间的关系）
将不稳定性（I）作为横轴，抽象程度（A）作为纵轴，那么最稳定、只包含抽象类和接口的组件应该位于左上角（0，1），最不稳定、只包含具体实现类，没有任何接口的组件应该位于右下角（1，0），他们连线就是主序列线，位于线上的组件，他们的稳定性和抽象程度相匹配，是设计良好的组件。
左下角位于（0，0）周围区域的组件，它们是非常稳定（注意这里的稳定指的是变更成本）并且非常具体的组件，因为它的抽象程度低，决定了它经常改动的命运，但是又有许多其他组件依赖它，改起来非常痛苦，所以这个区域叫做痛苦区。
右上角区域的组件，没有其他组件依赖它，它自身的抽象程度又很高，很有可能是陈旧的老代码，所以这个区域叫做无用区。
可以用点距离主序列线的距离 Z 来表示组件是否遵循稳定抽象原则，Z 越大表示组件越违背稳定依赖原则。
总结
在了解了什么是组件之后，我们很方便的根据应用程序描绘软件组件依赖/结构图，基于此，介绍了组件聚合需要遵循的基本原则：
- 无依赖环原则（ADP）
- 稳定依赖原则（SDP）
- 稳定抽象原则（SAP）
同时三原则存在互相限制，优秀的软件架构师需要而且能够在这三者之间进行平衡。
对于如何用组件构建系统，组件耦合原则：
- 无依赖环原则（ADP）
- 稳定依赖原则（SDP）
- 稳定抽象原则（SAP）
边界的解耦方式也可以分为3个层次：
- 源码层次：做了接口、类依赖上的解耦，但是放在同一个组件中，通常放在不同的路径下，和不完全边界的省略最后一步一样。
- 部署层次：拆分为可以独立部署的不同组件，比如 iOS 的静态库、动态库，真正运行时处于同一台物理机器上，组件之间通常通过函数调用通讯。
- 服务层次：运行在不同的机器上，通过 url 、网络数据包等方式进行通讯。
从上到下，（开发、部署）成本依次升高，如果低层次的解耦已经满足需要，不要进行高层次的解耦。所以不完全边界能解决的，不要用完全边界，低层次解耦能解决的，不要用高层次解耦。
