架構設計沒有最好的, 只有更合適的。
之前公司的app比較小， 然後更新的也比較慢，整體的架構設計不合理。現在公司的架構設計整體來說還是蠻合理的。
之前公司項目比較小， 人員也比較少， 採用MVC就基本搞定。現在公司業務需求需要不斷的更新， 開發人員也比較多，簡單的邏輯， 視圖和數據已經無法滿足， 這個時候就需要解決模塊的劃分， 如何劃分， 按照什麼標準來劃分，模塊間要如何協作這幾個問題， 在這其中， 模塊粒度的劃分是最關鍵的一步。
對於iOS這種面向對象編程的開發模式來說， 我們應該遵循以下五個原則， 即SOLID原則
- 單一功能原則：對象功能要單一， 不要在一個對象裏添加很多功能。
- 開閉原則：擴展是開放的， 修改是封閉的。
- 里氏替換原則： 子類對象是可以替代基類對象的。
- 接口隔離原則：接口的用途要單一， 不要在一個接口上根據不同入參實現多個功能。
- 依賴反轉原則：方法應該依賴抽象， 不要依賴實例。iOS開發就是高層業務方法依賴於協議
其中， 組件可以認爲是可組裝的、獨立的業務單元， 具有高內聚，低耦合的特性， 是一種比較適中的粒度。就像用樂高拼房子一樣， 每個對象就是一塊小積木。一個組件就是由一塊一塊的小積木組成的有單一功能的組合， 比如門、柱子、煙囪。
iOS組件，應該是包含UI控件、相關多個小功能的合集、是一種粒度適中的模塊。並且，採用組件的話，對於代碼邏輯和模塊間的通訊方式改動都不大。我們可以按照物理劃分， 也就是將多個相同功能的類移動到同一個文件夾下， 然後做成CocoaPods的包進行管理。
當然組件間也會有上下依賴關係， 也有上下的層次， 爲了方便管理和維護組件， 就要合理的對組件進行分層。公司的分層主要有三層
- 底層， 與業務無關的基礎組件 比如一些網絡層， 本地的圖片， 數據model解析， 流量統計， 路由，一些通用的WebView
- 中間層， 一般通用的業務， 不如分享功能，支付功能， 埋點等
- 最上層就是經常更新迭代的業務層
上面的每個功能都是一個組件， 這樣如果開發一個新的App就會很方便， 可以輕鬆的使用公司團隊開發的通用組件，也並不是所有的功能都適合做成組件， 只有那種被多種業務或者團隊需要多次使用的纔可以被抽成組件， 做成組件的時候， 就要嚴格的按照模塊粒度的標準來做， 因爲一般組件開發之後， 返工的成本很高， 幾乎也很少返工。
由於公司的項目比較大，也會有專門的基礎服務團隊，和架構組， 負責業務無關的通用組件以及一些用於多個app的和業務相關的通用組件的開發。
然後每個業務都有一個專門的團隊來進行開發。
由於公司的人員變更， 以及業務的更新迭代， 組件的文檔需要很清楚， 就會有效的減少溝通的成本