(2) 基於領域分析設計的架構規範-領域分析基礎

本系列目錄：

1. 改變與優點
2. 領域分析基礎
3. 讀寫隔離
4. 充血模型之實體
5. 充血模型之Service
6. 關於重構與落地

因爲整個架構規範很大程度上是基於領域驅動設計（Domain Driven Design,DDD）的思惟，因此，有必要在這裏和你們先介紹一下DDD的一些概念。

領域聚合

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

• 咱們主營的商品是甜品，計劃讓用戶能過經過微信小程序來完成下單到支付的整個流程
• 用戶可以在咱們的小程序主頁選擇甜品主食，而後選擇詳細的一些輔料搭配，最終下單，（爲了簡化，暫不考慮購物車，也就是一單隻有一個甜品）
• 目前只容許堂食，不考慮配送
• 對了，咱們偶爾還會須要派發一些優惠券，用戶能在支付的時候輸入優惠券進行抵扣（一次最多用一張）
• 咱們想可以記錄好每一個用戶從下單，支付，到製做完成的整個流程記錄

而後，咱們可以很快得出這樣一個模型圖

簡單來講就是：

• 一個用戶能夠建立多個訂單，固然也能夠不下單
• 一個訂單會產生至少一條訂單變動記錄（從建立開始）
• 一個訂單隻對應一種商品，假定商品的「輔料搭配」只做爲一個「備註」屬性存儲到商品
• 一個訂單最多使用一張優惠券，而優惠券，當時能夠一直不被使用

若是這個時候問你 你以爲那兩個模型類的相互關係是最緊密的呢？ 相信幾乎你們對這個答案沒有異議

可能你這時說不上來緣由，但至少從直覺來看，你們都會這麼選擇，並且確實也是如此

由於這是一個聚合——訂單聚合。

他們的關係很緊密，有多緊密？若是必定要挑一個最重要的因素來講，就是：訂單變動記錄不能離開訂單而單獨存在。對，他們必須在一塊兒，並且訂單是中心，變動記錄是它的旁支。若是訂單不存在了，或者不指定某一個訂單，那麼這個變動記錄則毫無心義。

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

那優惠券呢？優惠券不也只能用於訂單嗎？它不該該屬於"訂單的優惠券」嗎？

並不會，由於優惠券能夠停留在不被使用的狀態，在那時，它是脫離訂單而存在的，並且咱們能夠在不須要外界任何其餘領域的狀況下，直接對優惠券進行一些設置修改，這也說明了，它是一個獨立的領域，或者說獨立的聚合存在

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

分層模型

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

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

用戶界面層

其實這裏有些困惑，我不知道做者是否將前端應用也包含進來。若是沒有，那麼這裏可能就相似咱們說的網關，或者路由配置層之類。不過總之，這裏並非領域分析的重點。

應用層

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

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

「定義軟件能夠完成的工做」，咱們能夠理解這是一個應用服務的入口，一個功能單元，一個API，那麼，以SpringMVC爲例，那麼咱們開發時入口是什麼？天然是@Controller，若是須要事務支持，就在這裏加上@Transactional也沒問題，千萬不要認爲事務不加在@Service上就感受怪怪的，沒什麼好奇怪的，要擺脫這種思惟慣性。

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

領域層

核心業務邏輯，以後咱們討論的主要內容都在這一層。

基礎設施層

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

全部層容許調用下方層，反之則否則

下一篇：讀寫隔離