首先解決三個問題：
- 模塊粒度應該如何劃分？
- 如何分層？
- 多團隊如何協作？
顆粒度劃分
對於 iOS面向對象編程開發模式來說，我們應該遵循以下五個原則，即solid原則
- 單一功能原則：對象功能要單一， 不要在一個對象裏添加很多功能
- 開閉原則：擴展是開放的，修改是封閉的
- 里氏替換原則：子類對象是可以替代基類對象的
- 接口隔離原則：接口的用途要單一，不要在一個接口上根據不同的入參實現多個功能
- 依賴反轉原則：方法應該依賴抽象，不要依賴實例。iOS開發就是高層業務方法依賴於協議。
分層
- 底層可以是與業務無關的基礎組件，比如網絡、存儲等
- 中間層一般是通用業務組件，比如賬號、埋點、支付、購物車等
- 最上層是迭代業務組件，跟新頻率最高
組件化架構
一般分爲協議式和中間者兩種架構設計方案。
協議式架構設計主要採用的是協議式編程的思路：在編譯層面使用協議定義規範，實現可在不同地方，從而達到分佈管理和維護組件的目的。這種方式也遵循了依賴反轉原則，
缺點：1.缺少統一調度層，難於集中管理；2.定義模式過於規範，從而使得架構的靈活性不夠高。
中間者架構，採用中間者統一管理的方式，來控制App的整個生命週期中間件間的調用關係。同時，組件接口的設計也需要保持一致性，方便中間者統一調用。
解耦的精髓在於業務邏輯能夠獨立出來。所以，再考慮架構設計時，更多的還是需要在功能邏輯和組件劃分上做到同級解耦，上下層依賴清晰，這樣的結構才能使得上層組件易插拔，下層組件更穩固。