領域驅動設計，讓程序員心中有碼（四）

#領域驅動設計，讓程序員心中有碼（四）

----------------------追憶有關分層的古老往事

         我一直認爲，程序員也是藝術家，他們撰寫的每一行代碼，是獻給這大好世界的優美詩篇。不一樣的人，寫的代碼也許風格迥異。有的，如春風化雨潤物無聲，有的，如高山流水，曲高和寡，還有的如旱日春雷，先聲奪人。而若是說，代碼是詩篇，那麼代碼的分層藝術絕對是最早映入讀者眼簾的序幕了。

         分層，一直以來是一個很是經典的軟件工程學問題，提到分層，不管是資深或者新入門的開發者，或多或少都有本身的理解。    

         在8年前，我剛參加工做時，有幸參與了比較多項目的研發和維護過程，這些項目的開發者，大可能是比我年長几歲的軟件開發者。在他們的開發習慣中，每每會傾向於直接在代碼中寫入用戶界面、數據庫訪問等支持代碼，甚至有至關一部分狀況下，會把代碼寫入到用戶界面中，這意味着在用戶界面層，每每會寫入大量的代碼，說不定會超過上萬行代碼。我以爲能夠將這種設計，理解爲「單層架構「。

        再後來的項目開始有了一點點改變，這個時候的架構，被成爲「三層架構「。在.NET開發史上，三層架構成爲一種歷史悠久的框架，從十年前開始，一直到今天，依然是.NET開發者最爲熟練的技術框架。如圖所示，三層架構在客戶端和數據庫之間增長了一箇中間層，將有效的業務規則、數據訪問等放在業務層中進行處理。界面層主要使用對數據的綁定渲染，再經過數據層實現數據的提交處理。有的開發者說，三層架構通吃一切項目，彷佛全部的項目均可以用三層架構來套用。然而在實際工做中，每每會忽略了業務邏輯層，業務邏輯每每會放在界面層或數據層中，最終致使界面層和數據層充斥着臃腫的代碼，使人難以維護。

 

    

       MVC架構也是一種很是主流的技術架構，這種架構是一種很是優秀的架構，他將用戶界面層經過模型層最先來源於上世紀七十年代，爲Smalltalk語言所設計的一種模式，許多基於用戶界面的架構也受到了他的啓發。MVC架構，經過將邏輯、數據、界面顯示分離的形式，實現代碼的組織，普遍適用於桌面端或網頁程序的開發過程。這種架構的特色是耦合性低、重用度高、生產週期短、部署快。可是一樣因爲缺少明確的定義，以及代碼過於集中，致使代碼腐化問題很是嚴重。

 

    

      MVP架構是從MVC架構中演進出來的典型表明，這種架構經過Presenter來處理邏輯，Model提供數據，View負責顯示。固然，他和MVC的區別在於，數據的顯示每每是經過Presenter來進行的，全部的界面操做也都是在Presenter中實現，這意味着View層，只是單薄的一層。

 

         

    與此同時，開發者們也善於使用存儲過程或視圖等不一樣的方式寫入複雜的業務邏輯，期待的每每是若是是代碼發生變動時，只需對數據庫進行修改便可，而無需去修改已經部署在用戶端的大量的代碼。  使用存儲過程、觸發器或視圖等方式，時至今日，依然是備受關注的一種實現技術，尤爲是面向傳統產業開發的項目，例如面向製造業的工業控制系統，要進行程序的部署仍然須要很是繁瑣的流程，這意味着用戶層的部署相對來講不方便，而數據庫的變更反而更方便。          

　　不一樣類型的架構或設計的理念迄今仍深入的影響着開發者的思惟模式和工做方法，並最終或多或少的影響着軟件工程的實現。          

　　從高內聚，低耦合的軟件工程學基本原則來講，模塊與模塊之間的關係，稱爲耦合，而模塊內部的關係稱爲內聚。而分層的目的，正是爲了在知足這個基本原則的前提下，提升代碼的可用性和穩定性。過少的分層，意味着代碼可讀性必然很糟糕，甚至不利於軟件的編譯分發，而過多的分層，則一樣意味着模塊的維護將對總體過程代碼不便。          

      領域驅動設計認爲，若是代碼中，與領域相關的內容分散在不一樣的部分，那麼要進行業務和代碼的分析將變得難如下手。對用戶界面的簡單調整均可能意味着代碼邏輯的變化，而想要調整業務規則，可能須要開發者們去排查與之相關的全部部分，例如界面層，數據層，甚至是存儲過程和視圖，這種過程實際上已經沒辦法創建可用的業務模型，甚至沒辦法創建測試用例和單元測試的開展，只能靠開發者憑經驗去處理不一樣的狀況。爲了保證代碼的可用性，應當儘量的分析理清所使用的技術和手段，程序層次設計應當簡單明瞭，易於理解。          

　　在複雜系統設計中，分層是一種很是不錯的理念，其目的是爲了更好的實現關注度分離，使設計的每一個部分，既能獲得單獨的關注，也能維護系統內部複雜的交互關係。領域設計認爲，上述提到的幾種設計模式，每每是下面四種概念的某種變體。

•     用戶界面層（或者表示層），負責向用戶顯示信息和解釋用戶指令。這裏的用戶，既能夠是使用用戶界面的人，也能夠是另一個計算機系統。
•     應用層：定義軟件要完成的任務，而且只會表達領域概念的對象來解決問題。這一層實際上負責的是系統與應用層進行交互的必要渠道。
•     領域層（或模型層）負責表達業務概念、業務狀態信息以及業務規則。儘管技術細節由基礎設施層實現，但業務狀況狀態的反映則須要有領域層進行控制。領域層是業務軟件的核心。
•     基礎設施層：爲上面各層提供通用的技術能力：爲應用層傳遞消息，爲領域層提供持久化機制，爲用戶界面層繪製屏幕組件等等。基礎設施層還可以經過架構框架來支持4個層次減的交互模式。

        在傳統項目中，每每不見得會如此鮮明的劃分層次，可是在進行模型驅動設計的關鍵，正是須要將領域層從複雜的業務代碼中抽離出來。在設計過程當中，應當採起如下操做：

    一、給複雜的應用層次劃分層次；

    二、對每一個層次進行獨立的設計，使其具備內聚性而且只依賴於它的下層；

    三、採用標準的架構模式，只與上層進行鬆散的耦合。

    四、將全部與領域模型有關的代碼放在一個層中，並讓它與用戶界面層、應用層和基礎設施層的代碼分開。

    五、領域對象應當把重點放在如何表達領域模型上，而不須要考慮本身的顯示和存儲問題，也無需管理應用任務等內容。

    六、模型設計的目的是達到含義豐富、結構清晰、業務鮮明。

       適當的分層，每每會經過架構框架的形式予以體現。在項目開發過程當中，咱們一般會使用一些框架，這些框架每每來源於平時項目的積累或者互聯網大佬的知識分享。可是這些框架每每不見得徹底符合咱們的項目需求。領域驅動設計認爲，好的架構框架既能解決複雜技術問題，也能讓領域開發者集中精力去表達模型，而無需考慮其餘問題。然而使用框架很容易爲項目製造障礙，最終一樣會給人形成錯誤的理解，即，咱們這個項目很簡單，並不須要複雜的框架。然而，筆者認爲，大部分情形所認爲的不需框架的緣由，每每是項目確實很是簡單，或者開發者低估了項目的複雜度，或者因爲公司短視的觀點，而忽略了代碼的架構設計和分層與建模工做，這最終致使項目容易陷入泥潭。

　　固然，也一樣要剋制慾望，貿然選擇難以駕馭的框架，反而讓項目開發過程變得不可收拾。所以，要選擇性的運用框架來解決問題，明智和審慎的應用框架的價值，讓開發者專一於核心業務問題的建模工做，纔是提升開發效率和程序質量的手段。

 

原文出處：https://www.cnblogs.com/xiyuanMore/p/10166790.html