話說天下大勢，分久必合，合久必分。周末七國分爭，并入于秦。及秦滅之后，楚、漢分爭，又并入于漢。漢朝自高祖斬白蛇而起義，一統天下，后來光武中興，傳至獻帝，遂分為三國 —- 《三國演義》

關于iOS的架構，看多了MVVM，VIPER,MVC，MVP，MVCS….的介紹文章。真正實踐下來的估計也就是MVC和MVVM了。MVC是系統自帶的框架，自然用的多。而MVVM解決了Controller臃腫的問題，再加上神器RAC也被很多團隊接納，甚至有一段時間出現了很多的文章鼓吹該模式如何如何了得。而在設計或者采納一個架構的時候，我們到底在思考些什么？

設計各個類的職責和他們之間的關系。

用個比較晦澀的說法是：關鍵概念抽象與概念關系設計。打個蓋房子的比方吧，關鍵概念抽象就是搞到鋼筋混凝土磚瓦石塊的基礎材料，而概念關系設計就是如何組織這些基礎材料：鋼筋為骨，水泥為膠，添磚加瓦為墻面，然后一個房子的雛形就有了。其實，在我理解,『架構』設計也應當類似。從一個宏觀的層面進行分析和抽象，找到合適的概念，這是分解，而后再把這些概念通過各種關系操作搞到一起，這是合成。分分合合中滿足一定的質量約束，我們有了一個架構。

希望滿足的質量約束

提高復用度

懶是第一生產力

這句話依稀記得是之前的GM說的，印象頗深。因為，仔細想想，我們在做設計和編碼的時候，都有一個原始的沖動就是少寫點代碼。最好，產品經理需求變動之后，我們不改代碼就能夠滿足他們的需求。任他天翻地覆，我自以不變應萬變。而黃粱一夢驚破醒，現實如此骨感。往往做業務開發的時候，疲于奔命的改改改。其實，我們的內心也是抗拒這樣的，少改點多好。那怎么才能少改點？

一個比較直接的做法就是：拿來就用。就是我們一直在說的組合模式。假設輪子都已經造好，要造個車，就只需要考慮如何去構架這個車的骨架和去實施，而不用去重新發明輪子（當然，輪子質量約束不滿足需求的情況下是得重新發明的）。沒有過多的思維負擔和實施負荷，當然就省事了。我們擁有越多的輪子，我們就能越省事。復用啊復用，這個懶的入門寶典。

于是提高整個系統和系統內部組成單元（模塊，類，函數。。。）的復用性就是一個非常重要的質量約束。通常情況下，談及復用我們想到更多的是類和函數。我們之前寫過一個什么什么功能的函數了，現在拿來就用好了。其實，還有更高一個思維層次的概念：業務邏輯。我們希望業務邏輯中的代碼也是可以復用的。比如一個ViewController的渲染邏輯（把整個VC的樣式包括nav和view都渲染成紅色）。我們希望在寫一個VC的時候，能夠很方便的復用之前寫的這樣的業務邏輯，即使VC的根view已經發生了改變，不再是原來的類型。

足夠的擴展性

新的東西被引入是永恒不變的事情。可能是新的頁面，新的業務邏輯，新的功能….當新的需求的到達的時候，我們的架構是否能夠快速的接納他們，以優雅而且高效的方式來實現他們？而不是，每次新的功能來了，要么傷筋動骨的大動干戈；要么削足適履，湊合湊合得了。

我們希望我們的代碼能夠有序的生長。脈絡清晰，每一個新功能都能夠在原有的架構中找到自己合適的位置。于是架構的可擴展性（也可以理解為代碼的自動化）也是要追求的一個質量約束。這不是簡單的向前兼容，向后兼容的問題。而是要能夠以最小的代價，承載更多的需求。

關于可擴展性，更喜歡用函數來比喻。

f(x) = x^2 x屬于R

簡單的函數關系，對于無論什么樣屬于R的自變量x，我們都能準確的得到因變量f(x)的值。而一個理想狀態是，如果我們的架構如一個函數一般，對于未來的變化都進行了合適的抽象，無論你輸入是什么，都有對應的輸出，那該多好。

其他屬性

前面所說的兩個屬性，更多的是從系統的角度來思考的。當然我們從不同的角度來思考，還會要求我們的架構能夠滿足不能的質量約束。從運行的角度，我們希望CPU、內存、磁盤利用率好，沒有卡頓，從用戶的角度思考我們希望界面流暢。饕餮一樣，我們總是貪得無厭的想讓這個架構完美。然而，現實很骨感，我們只能先從幾個入手。

BY:yishuiliunian