spring基于領域分析設計的架構規范

本篇內容主要講解“spring基于領域分析設計的架構規范”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“spring基于領域分析設計的架構規范”吧!

領域聚合

讓我們用一個相對簡單的小電商系統來舉例，來說明幾個概念，這個電商系統的大概需求如下

• 我們主營的商品是甜品，計劃讓用戶能過通過微信小程序來完成下單到支付的整個流程

• 用戶能夠在我們的小程序主頁選擇甜品主食，然后選擇詳細的一些輔料搭配，最終下單，（為了簡化，暫不考慮購物車，也就是一單只有一個甜品）

• 目前只允許堂食，不考慮配送

• 對了，我們偶爾還會需要派發一些優惠券，用戶能在支付的時候輸入優惠券進行抵扣（一次最多用一張）

• 我們想能夠記錄好每個用戶從下單，支付，到制作完成的整個流程記錄

然后，我們能夠很快得出這樣一個模型圖

簡單來說就是：

• 一個用戶可以創建多個訂單，當然也可以不下單

• 一個訂單會產生至少一條訂單變更記錄（從創建開始）

• 一個訂單只對應一種商品，假定商品的“輔料搭配”只作為一個“備注”屬性存儲到商品

• 一個訂單最多使用一張優惠券，而優惠券，當時可以一直不被使用

如果這個時候問你 你覺得那兩個模型類的相互關系是最緊密的呢？ 相信幾乎大家對這個答案沒有異議

可能你這時說不上來原因，但至少從直覺來看，大家都會這么選擇，而且確實也是如此

因為這是一個聚合——訂單聚合。

他們的關系很緊密，有多緊密？如果一定要挑一個最重要的因素來說，就是：訂單變更記錄不能離開訂單而單獨存在。對，他們必須在一起，而且訂單是中心，變更記錄是它的旁支。如果訂單不存在了，或者不指定某一個訂單，那么這個變更記錄則毫無意義。

其中，Order被稱之為聚合根(Aggregate Root)，或者根實體(Root Entity)。所有的行為都從訂單出發，而類似訂單變更記錄這種非根實體，則不直接與外界打交道。

那優惠券呢？優惠券不也只能用于訂單嗎？它不應該屬于"訂單的優惠券”嗎？

并不會，因為優惠券可以停留在不被使用的狀態，在那時，它是脫離訂單而存在的，而且我們可以在不需要外界任何其他領域的情況下，直接對優惠券進行一些設置修改，這也說明了，它是一個獨立的領域，或者說獨立的聚合存在

至于分析出來的目的，在充血模型一章我們再詳細說明。

分層模型

下圖為《領域驅動設計》中所提到的分層架構

關于原書對四層的介紹，我在這里先不原文復述了，我以我的理解（或疑問），分別挑選重點進行介紹：

用戶界面層

其實這里有些困惑，我不知道作者是否將前端應用也包含進來。如果沒有，那么這里可能就類似我們說的網關，或者路由配置層之類。不過總之，這里并不是領域分析的重點。

應用層

這是一個和領域層的界限相對模糊的一層。在原書中，這一層的描述是這樣：

定義軟件可以完成的工作....它不包含處理業務規則或知識，只是給下一層中相互協作的領域對象協調任務、委托工作。

“定義軟件可以完成的工作”，我們可以理解這是一個應用服務的入口，一個功能單元，一個API，那么，以SpringMVC為例，那么我們開發時入口是什么？自然是@Controller，如果需要事務支持，就在這里加上@Transactional也沒問題，千萬不要認為事務不加在@Service上就感覺怪怪的，沒什么好奇怪的，要擺脫這種思維慣性。

“它不包含處理業務規則或知識”，并非完全“和業務無關”。廣義上來說，連一個商業項目的整個架構都是為業務來服務，就算是遵循了“開閉原則”，保證了“擴展性”，依舊是以業務方向做主導。所以，應用層也會涉及業務，但是卻非“核心邏輯”。那如何界定？我目前也沒有想到一個可以簡單描述出來的說法，只是做了一些相對簡單粗暴的規定：如果這個功能要求用到一些公共的組件，諸如文件上傳下載，EXCEL/WORD等文件解析等明顯是工具型做法，一般來說都能放在這一層。

領域層

核心業務邏輯，之后我們討論的主要內容都在這一層。

基礎設施層

持久化讀寫，公共組件如上面提到的文件下載工具等，還有比如RPC的框架組件等等，都屬于此層。這一層可以被上面的任何一層直接調用

到此，相信大家對“spring基于領域分析設計的架構規范”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！