开发到一定阶段必须要知道的组件化

如果你在京东图书频道搜索 组件化 或者 组件化开发，显示的几乎都是 Android组件化开发 或者 Android组件化架构 等等。类似Android这样的技术，它们本身就是可组件化实践。

再一个就是JS前端框架，在这个领域里也常常提组件化，比如VUE框架是组件化的实现，通过Vue.component来实现组件化开发，通常一个组件也就是一个小型的vm实例，前端的程序员同学大都在实现组件化的路上努力着。

我本身并没有开发过Android的应用，对JS也逐渐陌生，只是工作环境中接触这两个领域下的组件化。这篇文章我想说的是其它语言系统架构的组件化，比如JAVA。我们在架构的环境里面将组建分为两种，分别是可依赖和可配置。

可依赖

系统架构环境内的组件化，第一种是我们很常见的比如Apache下的commons包里面的类，我们工程里面几乎都会依赖，还有就是我们自己写了一组方向相同的类并组装成一个包，供其它模块来调用。

究竟哪些类应该被组合成一个组件呢，正如《架构整洁之道》这本书中所介绍的，这是一个非常重要的设计决策，应该遵循优秀的软件工程经验来行事。

这些优秀的实践经验，凝结成了三个与构建组件相关的基本原则，分别是

REP：复用/发布等同原则

软件复用的最小粒度要跟发布的最小粒度相同

CCP：共同闭包原则

有些类经常同时修改，并且修改的目的也相同，这些类应该放到同一个组件中

CRP：共同复用原则

不应该强制某一个组件的使用者去依赖他们不需要的东西

不过，我们在利用这三个原则的时候会发现，他们之间是一种竞争的关系，也就是不可能同时遵守，但如果只考虑其中的两个原则而忽略另外一个又会带来系统架构上的坏的后果。比如，只关注REP和CRP就会导致太多组件变更；只关注CCP和REP就会导致很多不必要的发布。下面这张图是组件聚合三大原则的张力图，图中的边线表示如果只考虑两种原则而带来的后果。

那么，我们应该如何做出取舍呢。还是参照上面这张图，《架构整洁之道》一书中给我们的建议是，我们考虑设计一个软件架构的时候，刚开始重心从张力图中的右侧开始，这个时候牺牲的是复用性。随着时间的推移，软件逐渐成熟的过程中，会对其它组件产生依赖，重心就会朝向张力图的左侧移动，从而开始考虑软件架构的复用性。

可配置

对于系统架构层面上的组件化，一个系统或者一整块大的功能，支持了很多种类型的业务场景，比如既支持了POP的业务，又支持了自营的业务；再比如既支持了国内，又支持了国外，一套代码全球部署。那么我们说以上这样的方式也可看成是国际化的部署。

在部署不同站点的同时，可以实现积木的方式搭建且按需部署。有时候需求方仅仅是需要一个最小的子集。比如，汽车能跑起来，主要因为有发动机、车轮、悬挂、车轴等，这些是最基本的组成；象后视镜、真皮座椅、自动防碰撞、自动驾驶等等这是增配部分。系统也是一样。

下图是一个系统组件化的概念结构图，包括基础服务层、业务服务层、业务应用层和业务场景。基础服务层是站在自身系统的角度去说，我们的依赖方，往往都是强依赖，缺少了不行的。业务应用层是我们的组件化可以支持的业务，业务场景在上文有提到。其实重点还是业务服务层，这一层是组件化的重点。

依照此图举例，业务服务层我们首先竖着分为七大模块，也就是这个系统或者这块业务一共分为七大可组件化的内容。其次用一条横线上下分为基础组件和增值组件(或者成为高配组件)。最后，一个方框圈住我们要面对的业务可组件化的最小子集。我们简称为：一竖、一横、一个方框。

模块、组件、插件

我们本文探讨的是组件，但另外两个内容常常被在一起说起，也就是模块和插件。在我看来它们三个是同质不同形的事物。模块是组件的基础，一个软件系统没有模块化则无从谈起组件化，试想一个大泥球的系统自身都分不清了，何谈组件化呢。模块化也很好理解现代化的开发工具比如IDEA，我们在使用的时候，每次创建的工程都是一个Module Project，类似下图这样。

说起插件，也可以举一些我们平时工作中常见的使用场景。比如Chrome浏览器中我们会下载安装插件，以便帮助我们更高效的处理我们的工作，Eclipse中的插件也是如此。象举例的这两种插件，它们都是成型的产品对接，使我们动态的"插入"到比如Chrome这个"大软件"系统里面。如何跟组件区分呢，组件大多数时候是在"编译"过程中的依赖，当然 上面提到的可配置的组件，也有插件的影子和"味道"。

模块是最基础的事物，它们是组件化、插件化的前提，是任何一个软件系统想要解耦的基础。组件是一个范围更广的定义，比插件的包含范围要大，也可以说插件是特殊的组件。我本人倒是觉得不必要太在意它们之间的区别，可以直接进化到 "看山不是山，看水不是水"的阶段，理解那个意思就好。

总结

组件化的好处，解耦。实际上组件化开发之后可以更快速的交付，节省需求响应处理时长，这也是业务人员所在意的，研发人员所看重的。当需求来了之后，可以通过配置化，几乎不用动代码，就像搭积木一样满足了业务方的需求，这一定是很爽的一件事情。诚然，这也是非常有难度的一件事情，因此组件化的开发，任重道远。