随着公司业务需求的不断迭代发展，工程的代码量和业务逻辑也越来越多，原始的开发模式和架构已经无法满足我们的业务发展速度了，这时我们就需要将原始项目进行一次重构大手术了。这时我们应该很清晰这次手术的动刀口在哪，就是之前的高度耦合的业务组件和功能组件，手术的目的就是将这些耦合拆分成互相独立的各个组件。
工程效果预览
组件化工程示例项目地址
组件化开源项目Git仓库地址
下面我们围绕这几个问题来展开讲解为什么要用组件化，它给我们带来哪些优势
各个组件该如何进行拆分，拆分的颗粒度该如何控制
如何从零到一搭建组件化架构项目
为什么要用组件化我们先来张图看看在没有使用组件化前，我们各个模块间的依赖关系
从上面这种各个业务组件的依赖关系来看，他们是互相依赖的，业务组件和业务组件间产生了严重的耦合关系，这样一来对我们工程的扩展性就会大大的降低，维护成本就会变高。
举个例子：假设某天产品经理说，咱们公司的业务发展的太好了，咱们的营销模块需要独立出来成一个单独的应用，以便于咱们可以添加更多高效的营销手段。这时我们就傻眼了，需要独立出一个app出来，这可怎么搞啊，营销模块的代码和其他的很多业务代码耦合在一起了，现在要独立出来，那就只能重新写一个营销应用了，之前的代码剥离不干净了。
从上面我们列举的一个简单的例子可以体会到：在项目没有做到真真意义上的组件化之前，各个业务模块和业务模块间的高度耦合，功能组件和功能组件间的高度耦合对未来公司的业务扩展来说，成本很高，不能做到同样业务逻辑的代码的高度复用，这样对我们开发来说也是效率的降低。
好了，有的同学可能会说，既然上面各个模块间耦合这么高，那我就来将这些耦合解耦，于是，可能会出现下面这张图的模块间的关系。
从下面这张图来看，我们发现，现在确实能做到各个业务模块间完全的解耦了，他们不再互相依赖了，同时我们引入了一个中间调度者的一个角色，现在是各个业务模块和这个中间调度者角色产出了严重的依赖。我们思考下发现，我们的各个业务模块依赖这个中间调度者，这个是完全正常的，因为他们需要这个调度者来做统一的事件分发工作，但是这个调度者却又依赖了每个业务模块，这层依赖是有必要的吗？我们回头想想真正的组件化开发是完全的去依赖化，这个依赖是完全没有必要的。例如：假设我们现在有一个新的B APP需要开发，这时我们也需要用到这个中间调度者组件，但是我们不能直接拿过来用，因为它又依赖了很多A App的业务组件。因此，我们的组件化架构设计又需要一次升级变更了，升级成如下图所示的模型。
从上面的这张图，我们可以看出，各个业务模块间只会依赖中间调度者，并且中间调度者不对各个模块产生任何的依赖。
好了，从上面的三张图之间的对比，我们就可以很好的理解为什么我们的工程急需要实现组件化架构开发了，以及各自的优劣势。
各个组件该如何进行拆分关于组件该如何拆分，这个没有一个完整的标准，因为每个公司的业务场景不一样，对应衍生出来的各个业务模块也就不一样，所以业务组件间的拆分，这个根据自己公司的业务模块来进行合理的划分即可。这里我们来说下整个工程的组件大致的划分方向
项目主工程：当我们工程完全使用组件化架构进行开发后，我们会惊奇的发现我们的主工程就成了一个空壳子工程。因为所有的主工程呈现出来的内容都被拆分成了各个独立的业务组件了，包括各个工具组件也是各自互相独立的。这样我们发现开发一个完整的APP就像是搭建乐高积木一样，各个部件都有，任我们随意的组合搭建，这样是不是感觉很爽。
业务组件：业务组件就是我们上面示例图所示的各个独立的产品业务功能模块，我们将其封装成独立的组件。例如示例Demo中的电子发票业务组件，业务组件A，业务组件B。我们通过组装各个独立的业务组件来搭建一个完整的APP项目。