目錄
- 模型驅動設計的構造塊-分離領域
- LAYERED ARCHITECTURE
模型驅動設計的構造塊-分離領域
在軟體中，雖然專門用于解決領域問題的那部分通常只占整個軟體系統的很小一部分，但其卻出乎意料的重要，我們需要著眼于模型中的元素并且將它們視為一個系統，絕不能像在夜空中辨認星座一樣，被迫從一大堆混雜的物件中將領域物件挑選出來，我們需要將領域物件與系統中的其他功能分離，這樣就能夠避免將領域概念和其他只與軟體技術相關的概念搞混了，也不會在紛繁蕪雜的系統中完全迷失了領域，
分離領域的復雜技術早已出現，而且都是我們耳熟能詳的，但是它對于能否成功運用領域建模原則起著非常關鍵的作用，所以我們要從領域驅動的視角對它進行簡要的回顧，
LAYERED ARCHITECTURE
在一個運輸應用程式中，要想支持從城市串列中選擇運送貨物目的地這樣的簡單用戶行為，程式代碼必須包括：(1) 在螢屏上繪制一個螢屏組件（widget）；(2) 查詢資料庫，調出所有可能的城市；(3) 決議并驗證用戶輸入；(4) 將所選城市與貨物關聯；(5) 向資料庫提交此次資料修改，上面所有的代碼都在同一個程式中，但是只有一小部分代碼與運輸業務相關，
軟體程式需要通過設計和編碼來執行許多不同型別的任務，它們接收用戶輸入，執行業務邏輯，訪問資料庫，進行網路通信，向用戶顯示資訊，等等，因此程式中的每個功能都可能需要大量的代碼來實作，
在面向物件的程式中，常常會在業務物件中直接寫入用戶界面、資料庫訪問等支持代碼，而一些業務邏輯則會被嵌入到用戶界面組件和資料庫腳本中，這么做是為了以最簡單的方式在短期內完成開發作業，
最早期的jsp就是這樣干的，jsp頁面直接寫后端代碼，現在php也可以這樣干，所以開發特別快
如果與領域有關的代碼分散在大量的其他代碼之中，那么查看和分析領域代碼就會變得例外困難，對用戶界面的簡單修改實際上很可能會改變業務邏輯，而要想調整業務規則也很可能需要對用戶界面代碼、資料庫操作代碼或者其他的程式元素進行仔細的篩查，這樣就不太可能實作一致的、模型驅動的物件了，同時也會給自動化測驗帶來困難，考慮到程式中各個活動所涉及的大量邏輯和技術，程式本身必須簡單明了，否則就會讓人無法理解，
要想創建出能夠處理復雜任務的程式，需要做到關注點分離——使設計中的每個部分都得到單獨的關注，在分離的同時，也需要維持系統內部復雜的互動關系，
軟體系統有各種各樣的劃分方式，但是根據軟體行業的經驗和慣例，普遍采用LAYERED ARCHITECTURE（分層架構），特別是有幾個層基本上已成了標準層，分層這種隱喻被廣泛采用，大多數開發人員都對其有著直觀的認識，LAYERED ARCHITECTURE的基本原則是層中的任何元素都僅依賴于本層的其他元素或其下層的元素，向上的通信必須通過間接的方式進行，
分層的價值在于每一層都只代表程式中的某一特定方面，這種限制使每個方面的設計都更具內聚性，更容易解釋，當然，要分離出內聚設計中最重要的方面，選擇恰當的分層方式是至關重要的，在這里，經驗和慣例又一次為我們指明了方向，盡管LAYERED ARCHITECTURE的種類繁多，但是大多數成功的架構使用的都是下面這4個概念層的某種變體，
給復雜的應用程式劃分層次，在每一層內分別進行設計，使其具有內聚性并且只依賴于它的下層，采用標準的架構模式，只與上層進行松散的耦合，將所有與領域模型相關的代碼放在一個層中，并把它與用戶界面層、應用層以及基礎設施層的代碼分開，領域物件應該將重點放在如何表達領域模型上，而不需要考慮自己的顯示和存盤問題，也無需管理應用任務等內容，這使得模型的含義足夠豐富，結構足夠清晰，可以捕捉到基本的業務知識，并有效地使用這些知識，
將領域層與基礎設施層以及用戶界面層分離，可以使每層的設計更加清晰，彼此獨立的層更容易維護，因為它們往往以不同的速度發展并且滿足不同的需求，層與層的分離也有助于在分布式系統中部署程式，不同的層可以靈活地放在不同服務器或者客戶端中，這樣可以減少通信開銷，并優化程式性能，
架構框架和其他工具都在不斷的發展，新框架將越來越多的應用技術問題變得自動化，或者為其提供了預先設定好的解決方案，如果框架使用得當，那么程式開發人員將可以更加專注于核心業務問題的建模作業，這會大大提高開發效率和程式質量，但與此同時，我們必須要保持克制，不要總是想著要尋找框架，因為精細的框架也可能會束縛住程式開發人員，
個人理解：現在的軟體開發一般都是前后端分離，后端使用springmvc或者springboot和服務加資料持久化層，通用的就是springboot+mybatis+mysql這一套，這個對于程式開發人員來說非常好理解，業務人員不理解也沒關系，以上內容現在已經是通用的開發架構模式，所以，這篇不用看也可以的，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/1050.html
標籤：領域驅動設計
上一篇：模型驅動設計的構造塊