1. 痛点
模块化之前，我们主要面临以下痛点：
1.业务边界不清晰
2.通用代码与业务代码耦合
3.代码、资源文件大量重复
4.常量满天飞
其中业务边界不清晰是最大的痛点，最直接的表现就是处处有雷，经常会引入新的 Bug，而且很多 Bug 往往不能从根本上解决，代码维护成本居高不下。
3 模块化过程
所谓模块化，是一个分而治之的过程，概念类似于 SOA，首先进行垂直拆分，过程中必然会催生出业务共享的 Common 模块，而 Common 又可以继续水平拆分，逐渐变薄，直到 Common 消失。
刚开始不需要完美的目标，简单粗暴一点，后续再逐渐改善。
3.1 抽取 Common
Common 层服务于所有的上层业务，是通用层，不允许引用业务层代码。
- 首先把 Common 层用到的 Business 层代码下放到各个业务
- 然后把多个 Business 之间共用的代码提取到 Common 层
- 资源文件的处理方式与代码一致
Common 层作为权宜之计，它的命运是向死而生，最终会诞生出许多功能独立的基础模块。而这个过程是漫长的，我们只能在业务隔离的同时，不断丰富 Common 模块，然后在某个节点将其再拆分成一个一个独立模块。
代码也逃不出分久必合、合久必分的的宿命。
3.2 业务隔离
业务模块之间不能互相依赖，只能单向依赖 common。
业务之间存在两种耦合关系：
1.页面耦合
2.功能耦合
要做到彻底隔离就必须打破这两种耦合关系：
- 页面解耦 - 跳转协议
- 功能解耦 - 模块间 RPC
3.2.1 统一跳转协议
页面解耦可以借鉴 Web 的设计原理，给业务模块中对外的页面定义一个 URI，然后页面之间通过 URI 跳转。
举个栗子，A、B 两个页面分属于不同的业务模块，在页面未解耦之前，A 如果要跳转到 B，必须要依赖 B 的模块，那么跳转代码会写成如下形式：
iOS
BbbViewController *bbbVC = [[BbbViewController alloc] init];
bbbVC.messageModel = messageModel;
[self.navigationController pushViewController:bbbVC animated:YES];
如果 A、B 之间还需要传递数据，就要共享常量、Model，耦合继续加重。
如果我们为 B 页面定义一个 URI - wsc://home/bbb，然后把共享的 messageModel 拍平序列化成 Json 串，那么 A 只需要拼装一个符合 B 页面 scheme 的跳转协议就可以了。
wsc://home/bbb?message={ "name":"John", "age":31, "city":"New York" }
URL Router 有很多种实现方式，网上资料也是多如牛毛，这里只提供一种思路。
iOS实现方式
- 通过 plist 文件保存 URI 到 Controller class 的映射
封装一个根据 URI 跳转到 Controller 的 SDK
页面跳转
[ZanURLRouter routeURL:@"wsc://home/bbb"];
3.2.2 模块间 RPC
转载：
https://youzanmobile.github.io/2017/04/14/youzan-app-modularization/
