最近在学习组件化，以下是部分学习心得：
Q1:为什么要模块化：
模块化结构是让工程结构更清晰，每个模块都只做一件事情，都有自己的一个命名，这样这个模块才能良性发展， 但是这个名字千万不要再叫Common了，试想下你有没有做过这样的事情：“哎呀，这块代码放哪都不太合适，放Common吧”， 日久以后，这个Common就变成了毒瘤，大家都依赖它，还一堆不相关的代码，这个Common模块就是我们设计原则第一点的反面教材： “非常不稳定，大量依赖，全是耦合，整个模块无法复用到其他app”, 所以删掉工程里面的Common吧，再遇到不知道放哪的代码，就要好好思考模块的设计，再不行如果具有可复用性就单建一个模块吧，为什么不可以呢？
Q2:怎么拆分：
越底层的模块，应该越稳定，越抽象，越具有高复用度。
不要让稳定的模块依赖不稳定的模块， 减少依赖
提升模块的复用度，自完备性有时候要优于代码复用
每个模块只做好一件事情，不要让Common出现
按照你架构的层数从上到下依赖，不要出现下层模块依赖上层模块的现象
业务模块之间也尽量不要耦合
基于分层架构下组件化，即组件可以分为表示层组件、业务层组件、持久层组件
基础模块下沉
Q3:终极目标：
单一职责，意味着一个模块、一个组件只做一件事，绝不多做。
正交性，意思是不重复，一个模块跟另一个模块的职责是正交的，没有重叠，组件也是一样。
单向依赖，模块之间最多是单向的依赖，如果出现A依赖B，B也依赖A，那么要么是A、B应该属于一个模块，要么就是整体的拆分有问题。一个完整的软件系统的模块依赖应该是一张有向无环图。（当然这是最终理想=。=）
紧凑性，模块、组件对外暴露的接口、属性应该尽可能的少，接口的参数个数也要少。
面向接口，模块、组件对外提供服务时最好是面向接口的，以便后期可以灵活的变更实现。
可以分branch开发，互不影响
可以分别写自己的单元测试
Q4:实现方案：
- Protocol注册方案 -需要load所有的protocol
优点：
没有硬编码
缺点：
1.每个Protocol都要向ModuleManager进行注册。
2.ModuleEntry是同时需要依赖ModuleManager、ModuleEntryProtocol和组件里面的页面或者组件两者的
- URL注册方案
JLRoutes本质可以理解为:保存一个全局的Map，key是url，value是对应的block，url和block都会常驻在内存中，这也是为什么casa反对使用URL跳转来实现组件化的原因，当注册的url很多了，对内存的消耗也是很大的。当打开一个URL时，JLRoutes就可以遍历这个全局的map，通过url来执行对应的block。
- Target-Action runtime调用方案
其设计的核心有下面几点：
- 基于 Runtime 来实现动态调用，避免模块注册，同时也避免产生反向依赖
- 通过 Category 暴露出更友好的接口，避免参数的构造和传递
- 在 target-action 之上构建 openURL 的处理
组件通过中间件通信，中间件通过 runtime 接口解耦，通过 target-action 简化写法，通过 category 感官上分离组件接口代码。
Q5:是否去model?
组件间调用时用字典传递数据，组件内调用时用model传递数据，这样即减少组件间数据对model的耦合，又方便了组件内使用model传递数据的便捷性。
参考资料：
三种方式优缺点：
//www.greatytc.com/p/9da81425d7c0
综合来看URLRoute+Procotol更适用于页面跳转这种业务较多的场景，同时配合持续集成环境，动态性更好(通过文本信息配置代替代码)，缺点是调用关系复杂，中间层比较庞大，需要配合持续集成环境才能有比较好的使用体验；Target-Action则更适合业务较杂的情况，核心代码很少，调用关系相对简单，缺点是硬编码场景较多，不过硬编码基本都在中间件里。
由于URLRoute+Procotol更适合有完整系统支持的场景，因此我们采用了Target-Action。该模式的特点也被充分验证：中间层代码量少、对项目的侵入性低，因此很快我们就完整组件化的工作了。
casa：
https://casatwy.com/iOS-Modulization.html觉得蘑菇街mgjmediator不对
http://mrpeak.cn/blog/module/排斥CTMediator
基于 URL Router、ModuleManager
代表：蘑菇街 Limboy 滴滴 美团基于 Target-Action、Runtime、Category
代表：安居客 casa
其他参考：
http://www.aopod.com/2017/12/10/a-url-routing-solution/
http://blog.csdn.net/KelvinFlying/article/details/75597287
