領域驅動設計-從貧血模型到充血模型-有解無憂

背景

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

一般畫風是這樣的，

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、但是如果只是小專案、求快的話，當然是開發成本低的貧血模型，

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/252555.html

標籤：設計模式

上一篇：試題基礎練習分解質因數

下一篇：領域驅動設計-從貧血模型到充血模型