系統分層泛談
今天同事提出了一個關於系統分層原因的問題。
做爲後端研發工程師，我們基本都聽過MVC模式/框架，但是目前我們系統拆分的情況，會遇到完全是服務端的系統，同時一個系統維護的研發人員並不多的情況下，那麼是否依然需要遵循類似MVC模式/框架的思想，對系統進行分層呢？
如果需要是爲什麼呢？如果不需要又是爲什麼呢？
基於上面的問題，系統分層的意義究竟又是什麼呢
對於這種設計類的問題，在工作中有一些零散的想法，正好藉此機會結構一下。
這個問題初看起來就如問題本身來說的一樣"顯而易見"， 分層當然會更容易管理，更容易實現。
從根本上來講，分層追求的是降低系統的開發維護成本。這是因爲對人類而言，一切複雜問題的處理思想都是分而治之。可以將人類看作只有一個"CPU線程"和"寄存器"，但只要有處理能力的上限都會從分治的思想受益。正如<<超體>>中所說，分類只是爲了簡化。
我們只知道一加一等於二，可是一加一根本不等於二，世界本沒有數字也沒有字母，我們把我們的存在塞入人類的框架體系當中，使之便於理解，我們創造了一個體系，以便忘卻原本難以理解的體系。
假如我們認可了分而治之的思想，那麼將這種思想運用到所謂的軟件中會產生什麼樣的反應和結果呢呢?
觀其形
首先，我們有了MVC，MVVW, MVP等等設計模式。這種設計模式是一種功能框架，將一個完整的功能拆分到不同的組件。試想經歷MVC等設計模式從無到有的開發者，一定會感覺有了這些很幸福。這些固定的模式就像青黴素一樣，能不關心細菌的種類進行使用，並且很大情況下不會出現問題。
從分層方式可以知道，上面的組件解耦方式屬於功能水平解耦，那麼也肯定也會存在垂直解耦。例如現在的微服務就是最好的例子。與水平解耦模式不同的是，垂直解耦有了一些業務的味道在裏面。
那麼對於這兩種組件解耦方式，是否可以找出共同的部分? 而且這些分層模式是否與現在火熱的DDD有關係?
辯其象，識其形，悟其道。
經過不斷探索，大師們總結組件設計原則SOLID和組件組合的原則REP, CCP, CRP等。這些原則理解起來比較繞，所以我們總結一下重點:
- 設計一個組件最重要的是單一職責和實現替換。
- 符合了單一職責的組件組裝應該以穩定性順序進行組合。
明白了這兩點，那麼DDD爲什麼會大火就有了一個合理的解釋，也是爲了更好地完成"單一職責"。
回答開題
不管分層還是不分層，我們最終目的都是爲了減少成本。
爲了達到這個目的，首先我們需要對系統職責有清晰的認知，其次需要對系統演進有一定的把握。
在此基礎上，再對當前已存在的特定分層模式(MVC, Cola)是進行簡化，來最大化分層模式的收益。