如何使用ABP進行軟體開發（2） 領域驅動設計和三層架構的對比
阿新 • • 發佈：2020-07-19
# 簡述
上一篇簡述了ABP框架中的一些基礎理論，包括ABP前後端專案的分層結構，以及後端專案中涉及到的知識點，例如DTO,應用服務層，整潔架構，領域物件（如實體，聚合，值物件）等。
筆者也曾經提到，ABP依賴於領域驅動設計這門方法論，由於其門檻較高，給使用者帶來了不少理解上的難度。尤其是三層架構對.NET開發者影響太深，有時很難對領域驅動設計產生直觀的理解。
在本文中，打算從傳統的簡單三層架構談起，介紹一個實際場景下的三層業務邏輯實現，然後再與領域驅動設計中的對應實現形成對比，以便讓開發者形成直觀具體的印象。
# 回顧三層架構
對於.NET開發者來說，三層架構相比都不陌生，這種架構，將程式碼層次劃分為使用者介面層，業務邏輯層、資料訪問層三個邏輯層次，實現了程式碼的關注度分離，且因其易於理解，已經成為眾多.NET開發者的"條件反射"。
## 三層架構簡介
三層架構就是為了符合“高內聚，低耦合”思想，把各個功能模組劃分為表示層（UI）、業務邏輯層（BLL）和資料訪問層（DAL）三層架構，各層之間採用介面相互訪問，並通過物件模型的實體類（Model）作為資料傳遞的載體，不同的物件模型的實體類一般對應於資料庫的不同表，實體類的屬性與資料庫表的欄位名一致。
三層架構區分層次的目的是為了 “高內聚，低耦合”。開發人員分工更明確，將精力更專注於應用系統核心業務邏輯的分析、設計和開發，加快專案的進度，提高了開發效率，有利於專案的更新和維護工作。
## 三層架構的分層邏輯
UI層：使用者介面層，實現與UI互動有關的邏輯。用於輸入使用者資料，輸出和呈現資料。在基於WebAPI的現代Web框架中，往往會使用MVC架構，將介面的資料行為，拆分成“模型-檢視-控制器”，實現了針對對UI層上關注度的進一步分離，
業務邏輯層： 業務邏輯層是使用者介面層和資料訪問層之間的轉換層，負責完成對資料的業務組裝，介面資料處理，將資料層的物件輸出（轉換）給使用者介面層。
資料訪問層：實現資料的儲存（持久化）操作，包括整合儲存過程，整合SQL語句，或整合現代ORM元件的形式，實現實現資料的儲存。
## 三層架構的應用
遇到專案，先從實體關係建模開始，使用PowerDesign或其他資料庫設計軟體分析業務與業務之間的關係，是一對多，還是一對一，還是多對多，繪製實體關係圖。
在進行軟體開發時，根據資料需求，定製想要的資料介面，從而實現以資料為核心的業務功能開發。
於是，在業務層次上，這種三層架構，進一步可以表示為如下分層結構：
在三層架構中，實體是業務的核心，所有的業務程式碼，都是圍繞實體展開，而左側三個功能層，其主要目的都是為了實現對實體的“增刪改查”操作。
以下程式碼簡述了一個訂單物件提交的全過程。（模型和程式碼僅供參考，不能直接執行）
```c#
///
/// UI控制器
///
public class OrderController
{
private OrderBll OrderBll = new OrderBll();
///
/// 新增訂單
///
///
///
///
public void AddOrder(int userId, int productId, int count)
{
OrderBll.AddOrder(userId, productId, count);
}
}
///
/// 業務邏輯層
///
public class OrderBll
{
private UserInfoDal userInfoDal = new UserInfoDal();
private ProductInfoDal productInfoDal = new ProductInfoDal();
private OrderDal orderDal = new OrderDal();
///
/// 新增訂單
///
/// 資料訪問層
///
/// 插入資料
///
///
public void Insert(Order order)
{
}
}
```
這種基於實體驅動建模的三層架構，變成了以資料為核心的“表模組模式”。
參見《企業應用架構模式》第87頁中關於表模組的介紹：
>表模組以一個類對應資料庫中的一個表來組織領域邏輯，而且使用單一的類實體來包含將對資料進行的各種操作程式。
>通常，表模組會與面向表的後端資料結構一起使用。以列表形式排列的資料通常是某個SQL呼叫的結果，它們被至於一個記錄集中，用於某一個SQL表。表模組提供了一個明確的基於方法的介面對資料進行操作。
>
/// 減少訂單數量
///
///
///
public void MinusOrder(int orderId, int minusCount)
{
Order order = orderDal.Get(orderId);
order.Count -= minusCount;
order.TotalPrice -= order.Price * minusCount;
orderDal.Update(order);
}
///
/// 增加訂單數量
///
///
///
public void AddOrder(int orderId, int addCount)
{
Order order = orderDal.Get(orderId);
order.Count += addCount;
order.TotalPrice += order.Price * addCount;
orderDal.Update(order);
}
```
這個程式碼寫起來非常快，因為只是新增了兩小段程式碼邏輯，而從減少訂單，到新增訂單，只是加法和減法的區別，自然而然就更快了。
但是，速度快，一定是優點麼？如果需求繼續持續不斷的累積呢。
例如，我們要修改訂單收貨人，收貨地址，修改訂單價格，是不是我們這種程式碼邏輯會越來越多，而且不同的業務邏輯互相攪合，使得後期的維護變得越來越困難？
所以，筆者認為，三層架構的缺點，就是前期開發速度太快，由於缺乏設計思想和設計模式的參與，太容易導致異味、垃圾程式碼、重複程式碼等問題產生。
所有這些問題，最終都被歸類於“技術債”的範疇。
>詳見維基百科。
>技術債：指開發人員為了加速軟體開發，在應該採用最佳方案時進行了妥協，改用了短期內能加速軟體開發的方案，從而在未來給自己帶來的額外開發負擔。
>這種技術上的選擇，就像一筆債務一樣，雖然眼前看起來可以得到好處，但必須在未來償還。
>軟體工程師必須付出額外的時間和精力持續修復之前的妥協所造成的問題及副作用，或是進行重構，把架構改善為最佳實現方式。
# 回顧領域驅動設計
## 領域驅動設計簡介
領域驅動設計思想來源於埃裡克埃文斯在2002年前後出版的技術書籍《領域驅動設計·軟體系統複雜性核心應對之道》，在這本書中，作者介紹了領域驅動設計相關的核心模式，例如：統一語言，模型驅動設計，領域實體，聚合，值物件，倉儲，限界上下文等模式。
隨著微服務的不斷興起，領域驅動設計也越來越受到網際網路人的廣泛追捧，在許多不同的行業應用實踐過程中，已經逐漸扮演了非常基礎的作用。無論是微服務架構下的服務粒度拆分，或者甚至是中臺應用，以及傳統的單體應用，都可以利用領域驅動設計思想下提供的模式，為應用程式的開發插上想象的翅膀。
## 領域驅動設計的分層邏輯
在上一篇部落格中，我們也介紹了領域驅動設計思想分層邏輯結構，共劃分為如下四個層次：
* 使用者介面層（或者表示層）：負責向用戶顯示資訊和解釋使用者指令。這裡的使用者，既可以是使用使用者介面的人，也可以是另外一個計算機系統。
* 應用層：定義軟體要完成的任務，並且只會表達領域概念的物件來解決問題。這一層實際上負責的是系統與應用層進行互動的必要渠道。
* 領域層：負責表達業務概念、業務狀態資訊以及業務規則。儘管技術細節由基礎設施層實現，但業務情況狀態的反映則需要有領域層進行控制。領域層是業務軟體的核心。
* 基礎設施層：為上面各層提供通用的技術能力：為應用層傳遞訊息，為領域層提供持久化機制，為使用者介面層繪製螢幕元件等等。基礎設施層還能夠通過架構框架來支援4個層次間的互動模式。
## 領域驅動設計的應用步驟
### 1）形成統一語言
統一語言是圍繞產品展開的一系列流程，方案，術語和名詞解釋及匹配的註釋。在領域驅動設計為每個應用設計成體系的【統一語言】是核心要點。
統一語言的形成是團隊成員協同參與，圍繞不同的需求，達成一致性理解的過程。
形成統一語言有時需要領域專家的參與，但有時可能難以達到這個條件，用需求代言人也同樣能夠滿足這個條件。
### 2）使用UML建模和畫圖
1. 建模的必要性
在我們工作過程中模型無處不在，不管是在紙上繪製的簡單模型，或者使用專業軟體繪製的各種模型，都是模型。領域驅動設計本身，依然依賴於模型驅動設計。
學會建模對於廣大開發者來說，都是一項基本技能，當然也是眾多最弱技能中的一種，因為廣泛依賴於實體關係建模的思維模式，使得開發者已經很難形成有效的模型設計思想，程式碼也越來越趨於【過程化】。
有時開發者甚至連實體關係建模這個步驟都會省略，直接使用Code First或甚至資料庫開始建表，這樣看起來速度非常快，但是太容易翻車了。
在團隊協作專案中，沒有良好的模型，僅憑高階開發者或有經驗開發者的“”一面之詞”進行設計，幾乎很難完成一個複雜專案。
而uml統一建模語言也是這樣的良好工具。
2. 使用哪些模型
筆者曾經有幸請教國內.NET技術圈擁有多年DDD實踐經驗的阿里技術專家，湯雪華老師，他指出：
>採用實體關係建模很容易看出物件與物件的關係，但僅此而已。資料並非物件，資料也無法看出行為，如果要依託實體關係建模來構建系統，往往需要開發者發揮自己的主觀抽象思維，根據客戶提供的資料或可用的原型，自行思考程式碼的邏輯實現。
>但顯然，具備優秀邏輯思維能力和設計思想的開發者鳳毛麟角，僅憑ER圖，程式碼寫出來往往很糟糕。
他認為，採用領域驅動設計，產品架構圖，系統架構圖，領域模型圖，類圖，關鍵業務場景的互動時序圖，這些是必不可少的。
* 產品架構圖：列出產品功能，表現出產品模組間的相關性。
圖來自[http://www.woshipm.com/pmd/1065960.html](http://www.woshipm.com/pmd/1065960.html)
* 系統架構圖：從技術層面列出系統模組組成關係。
原圖來自網際網路
* 領域模型關係圖：反映出各領域模型間的相關性，限界上下文，聚合，和聚合根。
來自[https://102.alibaba.com/detail?id=174](https://102.alibaba.com/detail?id=174)
3. 如何建模？
如果說程式碼語言是為了與其他開發者進行溝通交流，那我們建立的各種軟體設計模型將極大的方便不同領域的人員進行交流。建模也可以稱之為語言的一部分。利用uml建立類圖，是一種可以比較易於接受的方式。我們可以採用以下手段來建立領域模型。
1)建立一個與實現繫結的模型。初版的模型也許很簡陋，但是它可以成為一個基礎，然後在後期逐漸完善。
2)建立一種基於模型的通用語言或表達形式和機制。通過通用語言讓參與專案的所有人理解模型。
3)開發一個蘊含豐富知識的模型。模型不是單純的資料結構，它更是各類知識的聚合體。
4)提煉模型，模型應該能在專案過程中動態改變，發現新的概念就加進來，過時的概念就適時移除，避免臃腫。
5)頭腦風暴和實驗。模型在於實踐和應用，它需要專案參與者共同的努力，而頭腦風暴是發揮集體智慧的良好方式。對模型進行實驗或者進行場景的模擬，有利於讓模型更符合需求。
當然，對於領域專家而言，不同型別的模型也許無法理解，例如類圖可能過於複雜，可以使用畫圖的形式，通過解釋性的圖形，甚至紙面上的圖，更能直觀的表現出領域的邏輯層次。
這張來自TW分享的一張圖，就是一個基於.NET MVC的產品設計UML設計圖。
建模也並非這篇部落格所能講清楚的，包括筆者自己，也只是偶爾設計過用例圖，時序圖和類圖，可能需要在後期系統的學習一下。
### 3）程式碼實現
回到最開始的那個三層架構下的程式碼示例，如果採用領域驅動設計，大概如下圖所示：
回到開始那個示例程式碼，如果採用DDD的程式碼實現，大概是這樣的：
```plain
///
/// 應用服務層
///
public class OrderAppService
{
private OrderRepository _orderRepository;
private UserInfoRepository _userInfoRepository;
private ProductInfoRepository _productInfoRepository;
public OrderAppService(OrderRepository orderRepository, UserInfoRepository userInfoRepository, ProductInfoRepository productInfoRepository)
{
_orderRepository = orderRepository;
_userInfoRepository = userInfoRepository;
_productInfoRepository = productInfoRepository;
}
///
/// 新增訂單
///
///
///
///
public void CreateOrder(int userId, int productId, int count)
{
UserInfo userInfo = _userInfoRepository.Get(userId);
ProductInfo productInfo = _productInfoRepository.Get(productId);
if (userInfo != null && productInfo != null)
{
//新訂單
Order order = Order.CreateOrder(productId, userInfo.Address, userId, productInfo.Price, count);
_orderRepository.Insert(order);
}
}
///
/// 減少訂單數量
///
///
///
public void MinusOrder(int orderId, int minusCount)
{
Order order = _orderRepository.Get(orderId);
order.Minus(minusCount);
_orderRepository.Update(order);
}
///
/// 增加訂單數量
///
///
///
public void AddOrder(int orderId, int addCount)
{
Order order = _orderRepository.Get(orderId);
order.Add(addCount);
_orderRepository.Update(order);
}
}
///
///訂單物件
///
public class Order
{
///
/// 主鍵
///
public int Id { get; protected set; }
///
/// 地址
///
public string Address { get; protected set; }
///
/// 使用者id
///
public int UserId { get; protected set; }
///
/// 產品id
///
public int ProductId { get; protected set; }
///
/// 數量
///
public int Count { get; protected set; }
///
/// 單價
///
public double Price { get; protected set; }
///
/// 總價
///
public double TotalPrice { get; protected set; }
///
/// 建立訂單
///
///
///
///
///
///
///
/// 新增
///
///
public void Add(int count)
{
}
///
/// 減少
///
///
public void Minus(int count)
{
}
}
```
這段程式碼，最主要的變化是如下幾點：
1. 引入領域模型，在三層架構的示例程式碼中，我們建立了如下模型：
這個模型是當我們Entity Framework指令碼時生成的實體模型，在業內通常稱其為“貧血模型”。對人類來說，紅細胞負責把氧氣輸送到組織細胞，然後新陳代謝，產生ATP，產生動力。
而“貧血模型”這個術語恰如其份的表現出這類模型雖然還能有效的工作，但是需要由其他物件來驅動其完成動作的含義。
領域模型與貧血模型相比，更關注物件的行為，而關注行為的目的是建立帶有公共介面並與在現實世界觀察到的實體相似的物件，使得依照統一語言的名字和規則進行建模變得更加容易。
2. 將原來的Order物件抽象化建模為一個DDD實體。DDD實體是一個包含資料（屬性）和行為（方法）的POCO物件。
在《Microsoft .NET企業級應用架構實戰》書第9.2.2中指出了領域實體的特點：
>定義明確的身份標識。
>通過公共和非公共方法表示行為。
>通過只讀屬性暴露狀態。
>限制基元型別的使用，使用值物件代替。
>工廠方法優於多個建構函式。
3. 私有set或protected set：
在示例程式碼中將Order中的所有屬性設定為
```plain
public double TotalPrice { get; protected set; }
```
這樣的目的是為了避免對該屬性的隨意更改，使得開發者在對屬性進行操作過程中，多了一個環節，即需要謹慎思考這樣的程式碼修改，從行為角度來分析是否符合業務需要。
在設計時實體時，開放set可能會帶來嚴重的副作用，例如影響實體的狀態。
在張逸老師的《[領域驅動設計實戰，戰術篇第15課](https://gitbook.cn/gitchat/column/5cbed2f6f00736695f3a8699/topic/5cd3fe04e30c87051ad3d110)》中，作者指出：
>物件之間若要默契配合，形成良好的協作關係，就需要通過行為進行協作，而不是讓參與協作的物件成為資料的提供者。
>《ThoughtWorks 軟體開發沉思錄》中的“物件健身操”提出了優秀軟體設計的九條規則，其中最後一條提出：不使用任何 Getter/Setter/Property。
>作者 Jeff Bay 認為：“如果可以從物件之外隨便詢問例項變數的值，那麼行為與資料就不可能被封裝到一處。在嚴格的封裝邊界背後，真正的動機是迫使程式設計師在完成編碼之後，一定有為這段程式碼的行為找到一個適合的位置，確保它在物件模型中的唯一性。”
當然，在實際開發過程中，有時並不一定把get方法也設定為protected，畢竟有時候還需要有所妥協。
4. 將建立方法從業務邏輯層，移動到了領域物件Order中的靜態工廠方法。
```plain
///
/// 建立訂單
///
///
///
///
///
///
///
/// 新增
///
///
public void Add(int count)
{
}
///
/// 減少
///
///
public void Minus(int count)
{
}
```
大概修改過程是最容易造成領域知識丟失的地方，而通過封裝為方法，使得這個過程得以以受控的形式進行，有助於讓其他開發者通過暴露的方法。
但這樣做要確保所使用的命名規範符合統一語言，否則會重蹈貧血模型的覆轍。當然，在領域設計中，經常會糾結於哪些行為應該放在領域物件中，可以參考這樣的規則：
* 如果方法只處理實體的成員，它可能屬於這個實體。
* 如果方法訪問相同聚合的其他實體或值物件，它可能屬於聚合根。
* 如何方法裡的程式碼需要查詢或更新持久層，或者需要用到實體（或聚合）邊界以外的引用，它屬於領域服務方法。
# 對比分析
## 二者的對比
筆者整理了一個簡單的圖表來表現二者的對比關係。顯然，三層架構並非毫無優勢，領域驅動設計也並非銀彈。
| | 三層架構 | 領域驅動設計 |
|:----|:----|:----|
| 業務識別方法 | 結合瀑布模型，通過需求分析，形成資料字典，指導資料庫設計。 | 團隊協作形成統一語言，並從統一語言中提取術語，指導類、流程，變數，行為定義等。 |
| 業務參與者 | 具備IT知識的開發人員，業務人員只能提供需求，往往不能參與設計過程。 | 由需求提供者或客戶、開發者、測試、產品經理等組成的跨職能團隊全力參與。 |
| 建模方法 | 實體關係建模為主，有時可以用UML | 以UML方法為主，畫圖為輔 |
| 業務程式碼分層 | 業務程式碼理論上應該在業務邏輯層，但有時遊離在控制器、業務邏輯層或資料訪問層，甚至受依賴的其他業務邏輯中 | 業務程式碼在領域層，有時在領域物件上，有時在領域服務中。 |
| 修改程式碼的難易程度 | 隨時隨地想改就改 | 需要遵循一定的設計原則或步驟、流程 |
| 可維護性 | 專案簡單時，易於維護；複雜時，難於維護。 | 掌握方法時，維護難度比較平滑。 |
| 資料持久化 | 在資料訪問層中完成，有時可以適當複用；也有開發者將資料訪問層提取出倉儲的模板方法進行復用。 | 一般在倉儲層中實現，且倉儲一般是基礎設施，意味著除特定場景外，基礎設施不會依賴於領域而二外定製行為。 |
| 多業務邏輯的整合 | 一般在業務邏輯層中實現 | 一般在應用服務層實現。 |
| 可測試性 | 比較難以加入測試程式碼 | 易於加入測試程式碼；也可以根據UML使用TDD來進行開發。 |
## 該如何取捨？
下圖這種流傳已久，同樣來自馬丁弗勒老爺子《企業架構應用模式》。
表現了隨著軟體複雜度的逐漸提升，資料驅動設計和領域驅動設計模式兩種不同型別的設計模式的開發效率（時間）對比曲線。
* 資料驅動設計建立了一個比較平滑的發展軌跡，但是隨著拐點的到來，將變得越來越為難以維護，最終造出一個難以維護的“義大利麵”。
* 領域驅動設計，前期的起點確實比資料驅動設計要高很多，而且甚至在剛剛使用一段時間後，由於業務複雜度的提升，會迎來一個拐點。這個拐點有點像“鄧寧·克魯格效應”中遇到的“絕望之谷”，讓開發者和管理層感覺有點力不從心，不少企業最終又拆掉了他們的領域驅動設計搭建的軟體；
* 使用領域驅動設計，隨著複雜度的逐漸推移，軟體開發人員的信心越來越足，程式碼自然也能夠不斷演進，平滑發展，。
* 從長期來看，領域驅動建模將給複雜系統帶來更加高效的維護效能。
# 總結
本文介紹了三層架構和領域驅動設計兩種不同的設計思想中如何實現業務邏輯程式碼的過程，並對針對程式碼的維護性問題進行了分析。由於時間倉促，部分觀點、設計圖、程式碼可能還不夠成熟，還請大家批評指正。
下一篇將介紹ABP框架開發中的具體實踐步驟。