如何使用ABP框架（2）三层架构与领域驱动设计的对比
本文來自長沙.NET技術社區，原創：鄒溪源。全文共有8500字，讀完需耗時10分鐘。
題圖來自@pixabay
簡述
上一篇簡述了ABP框架中的一些基礎理論，包括ABP前后端項目的分層結構，以及后端項目中涉及到的知識點，例如DTO,應用服務層，整潔架構，領域對象（如實體，聚合，值對象）等。
筆者也曾經提到，ABP依賴于領域驅動設計這門方法論，由于其門檻較高，給使用者帶來了不少理解上的難度。尤其是三層架構對.NET開發者影響太深，有時很難對領域驅動設計產生直觀的理解。
在本文中，打算從傳統的簡單三層架構談起，介紹一個實際場景下的三層業務邏輯實現，然后再與領域驅動設計中的對應實現形成對比，以便讓開發者形成直觀具體的印象。
回顧三層架構
對于.NET開發者來說，三層架構相比都不陌生，這種架構，將代碼層次劃分為用戶界面層，業務邏輯層、數據訪問層三個邏輯層次，實現了代碼的關注度分離，且因其易于理解，已經成為眾多.NET開發者的”條件反射”。
三層架構簡介
三層架構就是為了符合“高內聚，低耦合”思想，把各個功能模塊劃分為表示層（UI）、業務邏輯層（BLL）和數據訪問層（DAL）三層架構，各層之間采用接口相互訪問，并通過對象模型的實體類（Model）作為數據傳遞的載體，不同的對象模型的實體類一般對應于數據庫的不同表，實體類的屬性與數據庫表的字段名一致。
三層架構區分層次的目的是為了 “高內聚，低耦合”。開發人員分工更明確，將精力更專注于應用系統核心業務邏輯的分析、設計和開發，加快項目的進度，提高了開發效率，有利于項目的更新和維護工作。
三層架構的分層邏輯
UI層：用戶界面層，實現與UI交互有關的邏輯。用于輸入用戶數據，輸出和呈現數據。在基于WebAPI的現代Web框架中，往往會使用MVC架構，將界面的數據行為，拆分成“模型-視圖-控制器”，實現了針對對UI層上關注度的進一步分離，
業務邏輯層：業務邏輯層是用戶界面層和數據訪問層之間的轉換層，負責完成對數據的業務組裝，界面數據處理，將數據層的對象輸出（轉換）給用戶界面層。
數據訪問層：實現數據的存儲（持久化）操作，包括集成存儲過程，集成SQL語句，或集成現代ORM組件的形式，實現實現數據的存儲。
三層架構的應用
遇到項目，先從實體關系建模開始，使用PowerDesign或其他數據庫設計軟件分析業務與業務之間的關系，是一對多，還是一對一，還是多對多，繪制實體關系圖。
在進行軟件開發時，根據數據需求，定制想要的數據接口，從而實現以數據為核心的業務功能開發。
于是，在業務層次上，這種三層架構，進一步可以表示為如下分層結構：
在三層架構中，實體是業務的核心，所有的業務代碼，都是圍繞實體展開，而左側三個功能層，其主要目的都是為了實現對實體的“增刪改查”操作。
以下代碼簡述了一個訂單對象提交的全過程。（模型和代碼僅供參考，不能直接運行）
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 | /// <summary> /// UI控制器 /// </summary> public class OrderController {private OrderBll OrderBll = new OrderBll();/// <summary>/// 新增訂單/// </summary>/// <param name="userId"></param>/// <param name="productId"></param>/// <param name="count"></param>public void AddOrder(int userId, int productId, int count){OrderBll.AddOrder(userId, productId, count);} }/// <summary> /// 業務邏輯層 /// </summary> public class OrderBll {private UserInfoDal userInfoDal = new UserInfoDal();private ProductInfoDal productInfoDal = new ProductInfoDal();private OrderDal orderDal = new OrderDal();/// <summary>/// 新增訂單/// </summary>/// <param name="userId"></param>/// <param name="productId"></param>/// <param name="count"></param>public void CreateOrder(int userId, int productId, int count){UserInfo userInfo = userInfoDal.Get(userId);ProductInfo productInfo = productInfoDal.Get(productId);//新訂單Order order = new Order();order.Address = userInfo.Address;order.UserId = userId;order.TotalPrice = productInfo.Price * count;order.ProductId = productId;orderDal.Insert(order);} } /// <summary> /// 數據訪問層 /// </summary> public class OrderDal {/// <summary>/// 插入數據/// </summary>/// <param name="order"></param>public void Insert(Order order){} } |
這種基于實體驅動建模的三層架構，變成了以數據為核心的“表模塊模式”。
參見《企業應用架構模式》第87頁中關于表模塊的介紹：
表模塊以一個類對應數據庫中的一個表來組織領域邏輯，而且使用單一的類實體來包含將對數據進行的各種操作程序。
通常，表模塊會與面向表的后端數據結構一起使用。以列表形式排列的數據通常是某個SQL調用的結果，它們被置于一個記錄集中，用于某一個SQL表。表模塊提供了一個明確的基于方法的接口對數據進行操作。
要進行一些實際的操作，一般需要多個表模塊的行為。
表模塊中的“表”一詞，暗示你數據庫中的每一個表對應一個表模塊。雖然大多數情況下都是如此，但也并非絕對。對于通用的視圖或其他查詢，建立一個表模塊也是有用的。事實上，表模塊的結構并非真的取決于數據庫表的結構，更多的是由應用程序能識別的虛擬表所標識，例如視圖或查詢。
在《Microsoft.NET企業級架構設計》一書中，作者認為“多數.NET開發者在成長的過程中都受到了表模塊模式的影響”。而相比之下，多數Java開發者則“深陷事務腳本的泥足”。
三層架構的優缺點
優點：
軟件分層架構的目的是為了分離關注點，三層架構也同樣如此，簡簡單單的三層代碼+ER圖，就能設計出一個良好結構的軟件系統。
這種模式，建立了以數據庫表為核心的開發模式，使得開發者能夠很便捷的對業務進行分析，進而驅動軟件功能的快速開發。
在應對簡單業務變遷過程中，由于能夠快速完成代碼的堆積，也使得開發者只需關注數據庫表的拼湊，就能快速的完成代碼開發，為開發項目帶來了不少便利。
除了簡單業務普遍采用三層，事實上許多復雜項目也會同樣采用，大概是由于三層架構的思想已經深入人心，許多資深開發者都形成的只要有表就能完成項目的開發的思維定勢。
缺點：
還是使用上述示例代碼，我們假設需求發生了變化，要求減少訂單的數量或增加訂單，我們會怎么做？也許，我們很容易就寫出了下面的代碼：
（當然，實際項目中，如果訂單已經提交，很少會直接對訂單數量進行修改的，往往會重新發起新訂單，但為了演示方便，我們先設定有這么一個奇怪的需求吧。）
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | /// <summary> /// 減少訂單數量 /// </summary> /// <param name="orderId"></param> /// <param name="minusCount"></param> public void MinusOrder(int orderId, int minusCount) {Order order = orderDal.Get(orderId);order.Count -= minusCount;order.TotalPrice -= order.Price * minusCount;orderDal.Update(order); } /// <summary> /// 增加訂單數量 /// </summary> /// <param name="orderId"></param> /// <param name="minusCount"></param> 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建模和畫圖
建模的必要性
在我們工作過程中模型無處不在，不管是在紙上繪制的簡單模型，或者使用專業軟件繪制的各種模型，都是模型。領域驅動設計本身，依然依賴于模型驅動設計。
學會建模對于廣大開發者來說，都是一項基本技能，當然也是眾多最弱技能中的一種，因為廣泛依賴于實體關系建模的思維模式，使得開發者已經很難形成有效的模型設計思想，代碼也越來越趨于【過程化】。
有時開發者甚至連實體關系建模這個步驟都會省略，直接使用Code First或甚至數據庫開始建表，這樣看起來速度非常快，但是太容易翻車了。
在團隊協作項目中，沒有良好的模型，僅憑高級開發者或有經驗開發者的“”一面之詞”進行設計，幾乎很難完成一個復雜項目。
而uml統一建模語言也是這樣的良好工具。
使用哪些模型
筆者曾經有幸請教國內.NET技術圈擁有多年DDD實踐經驗的阿里技術專家，湯雪華老師，他指出：
采用實體關系建模很容易看出對象與對象的關系，但僅此而已。數據并非對象，數據也無法看出行為，如果要依托實體關系建模來構建系統，往往需要開發者發揮自己的主觀抽象思維，根據客戶提供的資料或可用的原型，自行思考代碼的邏輯實現。
但顯然，具備優秀邏輯思維能力和設計思想的開發者鳳毛麟角，僅憑ER圖，代碼寫出來往往很糟糕。
他認為，采用領域驅動設計，產品架構圖，系統架構圖，領域模型圖，類圖，關鍵業務場景的交互時序圖，這些是必不可少的。
產品架構圖：列出產品功能，表現出產品模塊間的相關性。
圖來自http://www.woshipm.com/pmd/1065960.html
系統架構圖：從技術層面列出系統模塊組成關系。
原圖來自互聯網
領域模型關系圖：反映出各領域模型間的相關性，限界上下文，聚合，和聚合根。
來自https://102.alibaba.com/detail?id=174
如何建模？
如果說代碼語言是為了與其他開發者進行溝通交流，那我們建立的各種軟件設計模型將極大的方便不同領域的人員進行交流。建模也可以稱之為語言的一部分。利用uml建立類圖，是一種可以比較易于接受的方式。我們可以采用以下手段來建立領域模型。
1)建立一個與實現綁定的模型。初版的模型也許很簡陋，但是它可以成為一個基礎，然后在后期逐漸完善。
2)建立一種基于模型的通用語言或表達形式和機制。通過通用語言讓參與項目的所有人理解模型。
3)開發一個蘊含豐富知識的模型。模型不是單純的數據結構，它更是各類知識的聚合體。
4)提煉模型，模型應該能在項目過程中動態改變，發現新的概念就加進來，過時的概念就適時移除，避免臃腫。
5)頭腦風暴和實驗。模型在于實踐和應用，它需要項目參與者共同的努力，而頭腦風暴是發揮集體智慧的良好方式。對模型進行實驗或者進行場景的模擬，有利于讓模型更符合需求。
當然，對于領域專家而言，不同類型的模型也許無法理解，例如類圖可能過于復雜，可以使用畫圖的形式，通過解釋性的圖形，甚至紙面上的圖，更能直觀的表現出領域的邏輯層次。
這張來自TW分享的一張圖，就是一個基于.NET MVC的產品設計UML設計圖。
建模也并非這篇博客所能講清楚的，包括筆者自己，也只是偶爾設計過用例圖，時序圖和類圖，可能需要在后期系統的學習一下。
3）代碼實現
回到最開始的那個三層架構下的代碼示例，如果采用領域驅動設計，大概如下圖所示：
回到開始那個示例代碼，如果采用DDD的代碼實現，大概是這樣的：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 | /// <summary> /// 應用服務層 /// </summary> 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;?}/// <summary>/// 新增訂單/// </summary>/// <param name="userId"></param>/// <param name="productId"></param>/// <param name="count"></param>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);}}/// <summary>/// 減少訂單數量/// </summary>/// <param name="orderId"></param>/// <param name="minusCount"></param>public void MinusOrder(int orderId, int minusCount){Order order = _orderRepository.Get(orderId);order.Minus(minusCount);_orderRepository.Update(order);}/// <summary>/// 增加訂單數量/// </summary>/// <param name="orderId"></param>/// <param name="minusCount"></param>public void AddOrder(int orderId, int addCount){Order order = _orderRepository.Get(orderId);order.Add(addCount);_orderRepository.Update(order);} }/// <summary>///訂單對象?/// </summary>public class Order{/// <summary>/// 主鍵/// </summary>public int Id { get; protected set; }/// <summary>/// 地址/// </summary>public string Address { get; protected set; }/// <summary>/// 用戶id/// </summary>public int UserId { get; protected set; }/// <summary>/// 產品id/// </summary>public int ProductId { get; protected set; }/// <summary>/// 數量/// </summary>public int Count { get; protected set; }/// <summary>/// 單價/// </summary>public double Price { get; protected set; }/// <summary>/// 總價/// </summary>public double TotalPrice { get; protected set; }/// <summary>/// 創建訂單/// </summary>/// <param name="productId"></param>/// <param name="address"></param>/// <param name="userId"></param>/// <param name="price"></param>/// <param name="count"></param>/// <returns></returns>public static Order CreateOrder(int productId, string address, int userId, double price, int count){return new Order(){Address = address,UserId = userId,TotalPrice = price * count,ProductId = productId,};}/// <summary>/// 新增/// </summary>/// <param name="count"></param>public void Add(int count){}/// <summary>/// 減少/// </summary>/// <param name="count"></param>public void Minus(int count){}} |
這段代碼，最主要的變化是如下幾點：
引入領域模型，在三層架構的示例代碼中，我們建立了如下模型：
這個模型是當我們Entity Framework腳本時生成的實體模型，在業內通常稱其為“貧血模型”。對人類來說，紅細胞負責把氧氣輸送到組織細胞，然后新陳代謝，產生ATP，產生動力。
而“貧血模型”這個術語恰如其份的表現出這類模型雖然還能有效的工作，但是需要由其他對象來驅動其完成動作的含義。
領域模型與貧血模型相比，更關注對象的行為，而關注行為的目的是創建帶有公共接口并與在現實世界觀察到的實體相似的對象，使得依照統一語言的名字和規則進行建模變得更加容易。
將原來的Order對象抽象化建模為一個DDD實體。DDD實體是一個包含數據（屬性）和行為（方法）的POCO對象。
在《Microsoft .NET企業級應用架構實戰》書第9.2.2中指出了領域實體的特點：
定義明確的身份標識。
通過公共和非公共方法表示行為。
通過只讀屬性暴露狀態。
限制基元類型的使用，使用值對象代替。
工廠方法優于多個構造函數。
3. 私有set或protected set：
在示例代碼中將Order中的所有屬性設置為
| 1 | public double TotalPrice { get; protected set; } |
這樣的目的是為了避免對該屬性的隨意更改，使得開發者在對屬性進行操作過程中，多了一個環節，即需要謹慎思考這樣的代碼修改，從行為角度來分析是否符合業務需要。
在設計時實體時，開放set可能會帶來嚴重的副作用，例如影響實體的狀態。
在張逸老師的《領域驅動設計實戰，戰術篇第15課》中，作者指出：
對象之間若要默契配合，形成良好的協作關系，就需要通過行為進行協作，而不是讓參與協作的對象成為數據的提供者。
《ThoughtWorks 軟件開發沉思錄》中的“對象健身操”提出了優秀軟件設計的九條規則，其中最后一條提出：不使用任何 Getter/Setter/Property。
作者 Jeff Bay 認為：“如果可以從對象之外隨便詢問實例變量的值，那么行為與數據就不可能被封裝到一處。在嚴格的封裝邊界背后，真正的動機是迫使程序員在完成編碼之后，一定有為這段代碼的行為找到一個適合的位置，確保它在對象模型中的唯一性。”
當然，在實際開發過程中，有時并不一定把get方法也設置為protected，畢竟有時候還需要有所妥協。
將創建方法從業務邏輯層，移動到了領域對象Order中的靜態工廠方法。
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | /// <summary> /// 創建訂單 /// </summary> /// <param name="productId"></param> /// <param name="address"></param> /// <param name="userId"></param> /// <param name="price"></param> /// <param name="count"></param> /// <returns></returns> public static Order CreateOrder(int productId, string address, int userId, double price, int count) {? ? ? ?return new Order(){Address = address,UserId = userId,TotalPrice = price * count,ProductId = productId,}; } |
創建過程應該是一個非常嚴謹的過程，而原來在業務邏輯層中初始化對象的方法，隨意性比較高，很容易就出現開發者在創建過程中將無關屬性賦值的現象。
但如果把創建過程改成使用構造方法，又可能會造成可讀性問題，而使用工廠方法，并創建一個受保護的構造方法則不會造成這個擔憂。
將訂單新增內容和減少內容從業務邏輯層移動到了領域對象上，并封裝為方法。采用迪米卡法則，只暴露最小的參數，每次只對最該賦值的屬性進行操作，也容易約束開發者的操作。
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | /// <summary> /// 新增 /// </summary> /// <param name="count"></param> public void Add(int count) { }/// <summary> /// 減少 /// </summary> /// <param name="count"></param> public void Minus(int count) {} |
大概修改過程是最容易造成領域知識丟失的地方，而通過封裝為方法，使得這個過程得以以受控的形式進行，有助于讓其他開發者通過暴露的方法。
但這樣做要確保所使用的命名規范符合統一語言，否則會重蹈貧血模型的覆轍。當然，在領域設計中，經常會糾結于哪些行為應該放在領域對象中，可以參考這樣的規則：
如果方法只處理實體的成員，它可能屬于這個實體。
如果方法訪問相同聚合的其他實體或值對象，它可能屬于聚合根。
如何方法里的代碼需要查詢或更新持久層，或者需要用到實體（或聚合）邊界以外的引用，它屬于領域服務方法。
對比分析
二者的對比
筆者整理了一個簡單的圖表來表現二者的對比關系。顯然，三層架構并非毫無優勢，領域驅動設計也并非銀彈。
| 業務識別方法 | 結合瀑布模型，通過需求分析，形成數據字典，指導數據庫設計。 | 團隊協作形成統一語言，并從統一語言中提取術語，指導類、流程，變量，行為定義等。 |
| 業務參與者 | 具備IT知識的開發人員，業務人員只能提供需求，往往不能參與設計過程。 | 由需求提供者或客戶、開發者、測試、產品經理等組成的跨職能團隊全力參與。 |
| 建模方法 | 實體關系建模為主，有時可以用UML | 以UML方法為主，畫圖為輔 |
| 業務代碼分層 | 業務代碼理論上應該在業務邏輯層，但有時游離在控制器、業務邏輯層或數據訪問層，甚至受依賴的其他業務邏輯中 | 業務代碼在領域層，有時在領域對象上，有時在領域服務中。 |
| 修改代碼的難易程度 | 隨時隨地想改就改 | 需要遵循一定的設計原則或步驟、流程 |
| 可維護性 | 項目簡單時，易于維護；復雜時，難于維護。 | 掌握方法時，維護難度比較平滑。 |
| 數據持久化 | 在數據訪問層中完成，有時可以適當復用；也有開發者將數據訪問層提取出倉儲的模板方法進行復用。 | 一般在倉儲層中實現，且倉儲一般是基礎設施，意味著除特定場景外，基礎設施不會依賴于領域而額外定制行為。 |
| 多業務邏輯的整合 | 一般在業務邏輯層中實現 | 一般在應用服務層實現。 |
| 可測試性 | 比較難以加入測試代碼 | 易于加入測試代碼；也可以根據UML使用TDD來進行開發。 |
該如何取舍？
下圖這種流傳已久，同樣來自馬丁弗勒老爺子《企業架構應用模式》。
表現了隨著軟件復雜度的逐漸提升，數據驅動設計和領域驅動設計模式兩種不同類型的設計模式的開發效率（時間）對比曲線。
數據驅動設計建立了一個比較平滑的發展軌跡，但是隨著拐點的到來，將變得越來越為難以維護，最終造出一個難以維護的“意大利面”。
領域驅動設計，前期的起點確實比數據驅動設計要高很多，而且甚至在剛剛使用一段時間后，由于業務復雜度的提升，會迎來一個拐點。這個拐點有點像“鄧寧·克魯格效應”中遇到的“絕望之谷”，讓開發者和管理層感覺有點力不從心，不少企業最終又拆掉了他們的領域驅動設計搭建的軟件；
使用領域驅動設計，隨著復雜度的逐漸推移，軟件開發人員的信心越來越足，代碼自然也能夠不斷演進，平滑發展，。
從長期來看，領域驅動建模將給復雜系統帶來更加高效的維護效能。
總結
本文介紹了三層架構和領域驅動設計兩種不同的設計思想中如何實現業務邏輯代碼的過程，并對針對代碼的維護性問題進行了分析。由于時間倉促，部分觀點、設計圖、代碼可能還不夠成熟，還請大家批評指正。
下一篇將介紹ABP框架開發中的具體實踐步驟。
總結
以上是生活随笔為你收集整理的如何使用ABP框架（2）三层架构与领域驱动设计的对比的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 龙芯团队 在移值 MIPS64 下的.N
- 下一篇： 魔幻艰难的2020上半年！