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/
