更清晰的MVC分層架構

這兩天在網上粗淺的看了一下領域驅動設計DDD，這是一種經典的面向對象建模方法論，感受與傳統的開發模式有所差異，因此記錄一下個人感覺。

傳統MVC三層架構

一般，咱們習慣的業務建模方式是圍繞數據表的，先根據業務須要設計數據庫，再完成業務流程的開發。

在實現層面採用MVC分層框架，業務數據在3個層級之間流動（數據的流動性本質）。

雖然採用了MVC分層設計，可是在業務流程實現上仍舊是面向過程式，一般遵循這樣的開發模式：取數據 -> 處理數據 -> 存儲數據，是一種以數據爲中心的過程式思想。

你們能夠思考一下，你是否是也是這樣開發業務的？

領域驅動設計（DDD）

該理論提出了一種新的分層模式，核心是強調面向對象。

interfaces是表現層，仍舊負責數據渲染，好比渲染頁面，渲染json等等。

domain是領域層，是指具體的某一類實體與操做的類封裝，好比訂單與訂單相關的操做。

application是應用層，組裝多個domain，組成一個具體的業務流程，好比交易下單流程，可能須要調用訂單、用戶、反做弊等等domain。

對於訂單來講，咱們傳統MVC一般只把它當作數據庫記錄，是一個」貧血模型」，裏面只有訂單的各個屬性列，經過調用model層從數據庫獲取。同時，咱們會寫一個service層，封裝對訂單記錄的業務操做方法，即過程式的面向數據的開發模式。

而DDD則不一樣，它強調訂單是一類實體，具體某一條訂單則對應一個訂單對象。訂單對象具備本身的業務處理方法，數據和方法是封裝在一塊兒的。

此時，若是建立訂單須要獲取用戶信息，那麼就須要application層來作組裝：先獲取用戶對象，再調用訂單對象的方法傳入用戶對象來完成下單的一個流程。

application就是來作具體業務流程的一層，進行多個domain的組裝。

MVC與DDD的結合

沒有銀彈，多參考不一樣的思想，目標是如何優化業務設計與定製高效的開發規範。

我感受DDD本質就是讓屬於不一樣領域的功能內聚，而後在應用層組裝不一樣領域的功能便可。

而反觀咱們面向數據的思考方式，很容易作出這樣的事情：爲了實現一個跨領域的業務流程，直接將多種不一樣領域的業務邏輯實如今一塊兒，即把分屬於不一樣領域的邏輯一股腦的丟在應用邏輯層實現，致使了設計愈來愈混亂，複用性愈來愈低。

其實咱們也沒必要徹底參考DDD直接改形成面向對象的領域設計，畢竟團隊擅長的建模方式仍舊是圍繞數據的，而不是圍繞領域對象的。

咱們徹底能夠藉助DDD來優化MVC分層設計，也就是以領域的眼光來優化MVC的使用。

以前在百度的時候，公司推廣PHP Yaf框架的開發規範就提到很重要的一點，即遵循以下的分層設計：

• view
• controller
• page
• service
• model

結合DDD，咱們來從新設計一下每一層要作的事情：

• model：特定領域數據的數據讀寫，好比 訂單領域：
  • 通常來講，訂單分爲主表和擴展表，兩張表完整表達了訂單業務，因此我會把它倆做爲一個model實現。
• service：該層與model層一一對應，說白了將model視做領域的數據部分（純數據），service視做領域的方法部分，共同組成了相似DDD中的實體，只不過咱們仍舊是面向數據和過程的實現。
• page：與DDD的application層對應，組裝多個service構成業務流程，向controller返回結果。
• controller：解析請求，組裝參數，調用page完成業務流程，將page返回值進一步加工成view須要的具體樣子。
• view：直接渲染html或者Json等，不該該包含其餘的數據處理邏輯。

總結個人想法，service+model應該配對出現，page組裝多個service完成業務流程，controller只是page與view之間的協調者（不該該有任何業務邏輯），

另外，service+model應該按領域思想劃分，而不是按數據表劃分，這樣能夠解決大多數的聯表需求。

對於事務需求，應該在application層控制事務開關，依舊組裝多個service完成事務內操做，保證不一樣領域的邊界清晰。

注：關注做者微信公衆號，瞭解更多分佈式架構、微服務、netty、MySQL、spring、、性能優化、等知識點。

公衆號：《 Java大蝸牛 》