上篇分析了組件的通信方案，本篇繼續來討論如何將項目組件化。
一個組件化的項目，分以下三層：
第一層：殼工程
殼工程就是最終交付項目（也可以是臨時的體驗包）的主工程，負責各個組件的初始化，並將它們組裝在一起，管理整個項目的生命週期。
第二層：bundle 工程
bundle 工程即組件，這裏沿用手機淘寶提出的概念，一個 bundle 應該包含自己的 UI、圖片等資源、業務邏輯，可以獨立運行，完全不依賴殼工程，也絕對不能互相依賴，這就與普通 Model 的劃分有顯著的不同。
這樣拆分的組件，交與不同開發小組全權負責，各小組可以用自己熟悉的工具棧和開發方式，不必勉強配合一些“強制的條款”，從而釋放自己的創造力。
有些方案提出，將圖片等本地資源單獨作爲一個 bundle ，共用並不是劃分一個組件的充分條件，如果這個圖片庫只是提供一些界面元素，供各個 bundle 共用，可以下沉到基礎庫中，方便用API方法直接調用，不必通過 Route 來間接傳輸。
第一層與第二層通過Route通信，包括頁面跳轉和異步回調。
第三層：基礎庫
將各個 bundle 都使用的庫都放在這一層，如 AFNetworking 等，也可以是自己封裝的工具庫，如圖片濾鏡、Cache 等。當然，用於組件通信的 Route 庫實際上也在這層，作爲基礎能力提供，不需要根據任何具體 Bundle 改動。
基礎庫都是被各個Bundle直接引用的，因此把哪些代碼“下沉”到這一層，需要仔細斟酌，但並不模棱兩可：成爲一個基礎庫的顯著特徵是沒有具體的業務邏輯。
因此網絡API顯得有些特殊：
網絡API不可避免地包含了 Model，與業務線緊密相關，前文的組件化層次圖中將API庫放在基礎庫，是基於項目有統一的API設計、接口差異較小、Model 具有高共用性的情況，作爲基礎能力提供，可以減少代碼冗餘，但如果各個 bundle 是完全不同的業務線，API 規則差別較大，Model 爲 Bundle 獨立使用，則可以考慮直接將其放入各個 Bundle ，由各個業務小組獨立維護，更符合組件化思想。
基礎庫需要在項目中統一版本，畢竟，如果各個 Bundle 各自引入AFN 的不同版本，絕對是開發的災難；如果 Bundle 有對基礎庫的擴充怎麼辦？一個建議是由 Bundle 各自添加自用的分類。
小結
本節通過對組件的劃分討論，說明了組件化的架構思想，想必你已經對組件化的各個角色有了進一步概念，接下來通過一個 Demo 來說明實踐中的組件化是如何進行的，如果從本文中有所收穫，點個小❤️讓我知道：技術探索的路上有你陪伴。