spring基于領(lǐng)域分析設(shè)計(jì)的架構(gòu)規(guī)范

本篇內(nèi)容主要講解“spring基于領(lǐng)域分析設(shè)計(jì)的架構(gòu)規(guī)范”，感興趣的朋友不妨來看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“spring基于領(lǐng)域分析設(shè)計(jì)的架構(gòu)規(guī)范”吧!

領(lǐng)域聚合

讓我們用一個(gè)相對(duì)簡(jiǎn)單的小電商系統(tǒng)來舉例，來說明幾個(gè)概念，這個(gè)電商系統(tǒng)的大概需求如下

• 我們主營(yíng)的商品是甜品，計(jì)劃讓用戶能過通過微信小程序來完成下單到支付的整個(gè)流程

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

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

• 對(duì)了，我們偶爾還會(huì)需要派發(fā)一些優(yōu)惠券，用戶能在支付的時(shí)候輸入優(yōu)惠券進(jìn)行抵扣（一次最多用一張）

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

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

簡(jiǎn)單來說就是：

• 一個(gè)用戶可以創(chuàng)建多個(gè)訂單，當(dāng)然也可以不下單

• 一個(gè)訂單會(huì)產(chǎn)生至少一條訂單變更記錄（從創(chuàng)建開始）

• 一個(gè)訂單只對(duì)應(yīng)一種商品，假定商品的“輔料搭配”只作為一個(gè)“備注”屬性存儲(chǔ)到商品

• 一個(gè)訂單最多使用一張優(yōu)惠券，而優(yōu)惠券，當(dāng)時(shí)可以一直不被使用

如果這個(gè)時(shí)候問你 你覺得那兩個(gè)模型類的相互關(guān)系是最緊密的呢？ 相信幾乎大家對(duì)這個(gè)答案沒有異議

可能你這時(shí)說不上來原因，但至少?gòu)?strong>直覺來看，大家都會(huì)這么選擇，而且確實(shí)也是如此

因?yàn)檫@是一個(gè)聚合——訂單聚合。

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

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

那優(yōu)惠券呢？?jī)?yōu)惠券不也只能用于訂單嗎？它不應(yīng)該屬于"訂單的優(yōu)惠券”嗎？

并不會(huì)，因?yàn)閮?yōu)惠券可以停留在不被使用的狀態(tài)，在那時(shí)，它是脫離訂單而存在的，而且我們可以在不需要外界任何其他領(lǐng)域的情況下，直接對(duì)優(yōu)惠券進(jìn)行一些設(shè)置修改，這也說明了，它是一個(gè)獨(dú)立的領(lǐng)域，或者說獨(dú)立的聚合存在

至于分析出來的目的，在充血模型一章我們?cè)僭敿?xì)說明。

分層模型

下圖為《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》中所提到的分層架構(gòu)

關(guān)于原書對(duì)四層的介紹，我在這里先不原文復(fù)述了，我以我的理解（或疑問），分別挑選重點(diǎn)進(jìn)行介紹：

用戶界面層

其實(shí)這里有些困惑，我不知道作者是否將前端應(yīng)用也包含進(jìn)來。如果沒有，那么這里可能就類似我們說的網(wǎng)關(guān)，或者路由配置層之類。不過總之，這里并不是領(lǐng)域分析的重點(diǎn)。

應(yīng)用層

這是一個(gè)和領(lǐng)域?qū)拥慕缦尴鄬?duì)模糊的一層。在原書中，這一層的描述是這樣：

定義軟件可以完成的工作....它不包含處理業(yè)務(wù)規(guī)則或知識(shí)，只是給下一層中相互協(xié)作的領(lǐng)域?qū)ο髤f(xié)調(diào)任務(wù)、委托工作。

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

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

領(lǐng)域?qū)?/h4>

核心業(yè)務(wù)邏輯，之后我們討論的主要內(nèi)容都在這一層。

基礎(chǔ)設(shè)施層

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

到此，相信大家對(duì)“spring基于領(lǐng)域分析設(shè)計(jì)的架構(gòu)規(guī)范”有了更深的了解，不妨來實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！