背景

領域模型對象只是用來存儲應用的數據。業務邏輯位于服務層中，管理域對象的數據。在服務層中，應用的每個實體對應一個服務類。這種模式大家是不是很熟悉，尤其是在中小項目或者項目剛啟動的時候，都是怎么方便怎么來；沒錯，這就是貧血模型。

一般畫風是這樣的。

1、Web層：接收用戶輸入，將數據傳至服務層；

2、服務層：處理業務邏輯、權限管理與授權，并與存儲層通信；

using BQoolCommon.Interface.Repository.Dapper; using BQoolCommon.Interface.Service; using BQoolCommon.Models.BQoolCommon_SetMain; using BQoolCommon.Models.Enum; using BQoolCommon.Models.ViewModel; using System; using System.Collections.Generic; using System.Configuration;namespace BQoolCommon.Service {public class UserPermissionService : IUserPermissionService{private readonly IInnerSiteMapDapperRep _innerSiteMapDapperRep;private readonly IInnerSiteMapService _innerSiteMapService;private readonly IAccountChannelRelService _accountChannelRelService;private readonly IUserMgmtService _userMgmtService;public UserPermissionService(IInnerSiteMapDapperRep innerSiteMapDapperRep,IInnerSiteMapService innerSiteMapService, IAccountChannelRelService accountChannelRelService, IUserMgmtService userMgmtService){_innerSiteMapDapperRep = innerSiteMapDapperRep;_innerSiteMapService = innerSiteMapService;_accountChannelRelService = accountChannelRelService;_userMgmtService = userMgmtService;} .................................................

3、存儲層：與數據庫進行通信，對數據進行持久化；

using System.Linq; using BQoolCommon.Interface.Factory; using BQoolCommon.Interface.Repository.Entity; using BQoolCommon.Models.BQoolCommon_SetMain; using BQoolCommon.Models.ViewModel;namespace BQoolCommon.Repository.Entity {public class WeChatSubscribeEntityRep : GenericEntityRep<WeChat_Subscribe>, IWeChatSubscribeEntityRep{public WeChatSubscribeEntityRep(IBqoolSetMainDbContextFactory factory) : base(factory){}} }

問題窺探

問題出在了服務層，他承受了太多的職責，像業務邏輯、權限檢查等等，這違反了單一職責原則，并產生了大量的依賴。當業務復雜度上升時，服務層所包含的代碼將會非常龐大和復雜。服務層需要包含應用邏輯、用戶會話的管理；領域層應該包含業務邏輯，可以處理與業務相關的會話狀態。

改進思路

我們需要將業務邏輯從服務層移動到領域模型中，這樣的好處是，服務層可以只負責應用邏輯（如數據有效性驗證、授權檢查、開始結束事務等），領域模型可以專門負責其相關的業務邏輯。以電商系統來舉例，架構設計時完全可以針對訂單、商品、庫存等多個領域模型進行建模，相關的業務可以分別放到不同的領域模型中，一些很有可能重復的業務代碼都會被集中到一處，從而降低了復制-粘貼的可能性，這就是充血模型。

影響

充血模型將服務類變得更小，使之只負責單一的職責。例如商品的CRUD和其他操作，就可以將其放到兩個不同的服務類中，一個負責商品的CRUD操作，另外一個負責與商品相關的其他操作。這樣就能使服務類變得小巧、松散、可測試了，同時還能降低其他人理解與重用的成本。

總結

1、從規范和長遠來看肯定是充血模型合適些。

2、但是如果只是小項目、求快的話，當然是開發成本低的貧血模型。

總結

以上是生活随笔為你收集整理的领域驱动设计-从贫血模型到充血模型的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。