如何運用領域驅動設計 - 作業單元

目錄

• 概述
• 直接看東西
• 什么是作業單元
• 如何實作作業單元
  • 懶的模式
  • 實作思路
  • 落地代碼
• 缺陷
• 總結

新年伊始，祝大家喜樂如意，愛和幸福“鼠”不盡！?. ?_?.??

概述

在上一篇 《如何運用領域驅動設計 - 存盤庫》 的文章中，我們講述了有關倉儲的概念和使用規范，倉儲為聚合提供了持久化到本地的功能，但是在持久化的程序中，有時一個聚合根中的各個領域物件會分散到不同的資料庫表里面；又或者是一個用例操作需要操作多個倉儲；而這些操作都應該要么同時成功，要么同時失敗，因此就需要為這一系列操作提供事務的支持，而事務管理就是由作業單元來提供的，在上一篇中，可能已經提到了作業單元，但是僅僅是一筆帶過，現在我們就來詳細的探究該如何更好的來實作作業單元，（文章的代碼片段都使用的是C#,案例專案也是基于 DotNet Core 平臺），

直接看東西

在上一篇文章中，已經為大家提供了一個Github的Demo，如果已經下載過該Demo的同學，您現在直接進行Pull就可以獲得最新的版本了；如果還沒有下載該Demo的同學也可以戳下方的跳轉鏈接獲取，

GitHub 地址，點擊直達喲

在這里我們可以先來看一下，該專案的應用代碼是什么樣子：

[HttpPost]
public ActionResult<string> Add()
{
    //使用倉儲來處理聚合
    _itineraryRepository.Add(
        new Itinerary(
            "奧特曼",
            "賽文奧特曼",
            "杰克奧特曼",
            "佐菲奧特曼",
            "泰羅奧特曼"));

    _itineraryRepository.Add(
        new Itinerary(
            "蓋亞奧特曼",
            "戴拿奧特曼",
            "阿古茹奧特曼",
            "迪迦奧特曼", ""));

    return "success";
}

[HttpGet]
public ActionResult<long> Get()
{
    var count = _itineraryRepository.GetCount();
    return count;
}

這是在Aspnet Core的Controller中的代碼，也就是對外提供的Api，可以看到我們僅僅只是通過倉儲的呼叫就完成了所有的操作，（ps:原諒我該演示api沒有遵循restful風格(￣▽￣)"，還有就是那些奧特曼，，，），

您可能會說，這里沒有做操作，那肯定是在 ItineraryRepository 里面做了手腳，好吧，下面我們來看看該倉儲的實作，

public class ItineraryRepository
        : EFRepository<UowAppDbContext, Itinerary, Guid>
{
    public void Add(Itinerary itinerary) => DbContext.Set<Itinerary>().Add(itinerary);
}

是的，它也只有這么一點點代碼，而作為后期的業務擴展和維護，我們只需要完善我們的Itinerary聚合（為它擴展行為和增加物體或值物件）以及ItineraryRepository倉儲（為它添加對外檢索意圖的方法）就可以了，

這種做法的好處可能您很快就能發現：在我們代碼中處處都是關于領域物件的操作，盡可能的避免其它基礎構建或功能支持組件來干擾程式，除了代碼量的減少之外，它也讓可讀性有著明顯的提高，如果在此基礎上能夠構建出明確而干凈的聚合根，那么您的程式將具備更高的可擴展性，

好吧，回到我們今天的主題：作業單元，其實上面的代碼就是對倉儲中作業單元的巧妙運用，它其實在后面默默的支持著程式的正常運轉，這是在呼叫層面上我們完全感覺不到它的存在而已，下面就為您介紹它是怎么作業和實作的，

什么是作業單元

按照國際管理呢，這一章節都是解讀有關原著《領域驅動設計:軟體核心復雜性應對之道》 中的解釋，但是！！！有關作業單元的概念在書里并沒有被明確的提及到，所以為了證明我們確確實實是在前人的基礎理念上來實踐，而不是胡編亂造自己隨便弄了一個概念出來，我特地去找了另外一本較為權威的領域驅動設計教材：《領域驅動設計模式、原理與實踐》 ，在該書中對作業單元的解釋如下：

事務管理主要與應用程式服務層有關，存盤庫只與使用聚合根的單一集合的管理有關，而業務用例可能會造成對多個型別聚合的更新，事務管理是由作業單元處理的，作業單元模式的作用是保持追蹤業務任務期間聚合的所有變化，一旦所有的變化都已發生，則之后作業單元會協調事務中持久化存盤的更新，如果在將變更提交到資料存盤的中途出現了問題，那么要確保不損壞資料完整性的話，就要回滾所有的變更以確保資料保持有效的狀態，

其實上文的話真的很好理解（相對于原著而言(￣y▽,￣)╭ ），首先我們可以得到的第一個結論：事務管理其實是應用服務層干的事，第二個結論：事務的協調管理都是由作業單元來負責的

所以，我們千萬不能因為作業單元和倉儲有聯系就將它放置在領域層里面：事務的提供往往是由資料庫管理程式來提供的，而這一類組件我們一般將它們放置在基礎構架層，而領域層可以依賴于基礎構架層，所以千萬要注意，保持您的領域層足夠干凈，不要讓其它的東西干擾它，也更不要將事務處理這類東西放到了您的領域層來，（這一點，您會在后期MiCake<米蛋糕>的使用中看到詳細的案例），

如何實作作業單元

實作作業單元，就是要實作倉儲中的事務操作，您可能已經看到過有些實作Repository的框架，它的寫法是注入一個unitOfWork,然后從uow中提取一個倉儲，然后再用倉儲來完成聚合根的持久化操作，類似的代碼就像這樣：

var yourRepository = uow.GetRepository<yourRepository>();
yourRepository.Add(yourEntity);

uow.Commit();

這樣做沒有一點點的問題，而且是對作業單元和倉儲模式的完美實作，uow作業單元中維持了一個事務，從該作業單元中創建的每一個倉儲都可以獲得該事務，倉儲完成了自己的操作之后，作業單元使用Commit方法告訴事務管理器，該事務完成，

夏目去參加了妖怪的聚會，一回到家，貓咪老師就發現了它沾染了妖怪的味道

當倉儲的操作沾染上了作業單元的事務，它也就受到了事務的管理

如果您喜歡這種實作模式，可以參考 threenine的Threenine.Data專案，

懶的模式

其實在剛開始，為 MiCake(米蛋糕) 選取作業單元實作方案的時候，我也打算采用這種方式，但是在思考了一天之后，我還是放棄了，因為我發現這種模式在完成每一次倉儲操作的時候，必須要從作業單元中去獲取，在Aspnet Core中，不得不在Controller中注入作業單元物件，然后再從該物件里面去獲取倉儲，這顯然削弱了依賴注入所為我們提供的依賴閱讀性（原本在建構式中，我能看出我需要注入的是A倉儲，但是現在我看到的只有作業單元），

其實最重要的一點就是：我太懶啦 o_o ....， 為什么每次都要去多寫一個uow.GetXXXXX()，每使用一個倉儲就要多寫一次獲取陳述句，我就不能好好的只使用倉儲嗎？ 所以在這個想法的強烈刺激下，我選取了另外的實作方法，

接下來，就讓我們來實作最開始演示代碼中的作業單元吧，哦，對了，忘記說了，無論是演示的Github Demo還是本次的博文，我們都選取了Entity Framework Core來作為資料持久組件，所以有些小伙伴會說，那我使用Dapper或者原生的ADO怎么辦？ 其實思路都是一樣的，您也可以在看了EFCore的版本后，自己寫出對應的作業單元版本，如果有機會的話，歡迎在Github的Demo上直接添加，就可以提交供更多的同學參考啦，

實作思路

• 找出當前資料庫持久組件中具有事務特征的物件（比如在EF中就是DbContext）
• 創建一個容器去容納這些物件
• 作業單元就是該容器的實作，它掌管了這些事務物件，并對外公布了提交事務的方法
• 作業單元管理器負責了對作業單元的創建作業

腦袋里有了這些還比較模糊的互動物件之后，我們可以來想一下一個倉儲完成添加聚合根的操作是怎么樣的：

• 在訪問該API之前：使用作業單元管理器創建一個作業單元
• 訪問API中的倉儲時候：構造一個事務特征物件，并開啟一個事務
• 事務開啟完成之后：將該事務特征物件嘗試放入到當前作業單元
• 倉儲事務操作完成后：呼叫作業單元的提交方法，完成事務的提交，保證倉儲的資料一致，
• 事務完成后：釋放上面的各個物件

雖然步驟好像有5步，但總結下來，就是將具有事務的物件放置到作業單元中，讓它去負責提交，對！就是這么簡單，該方法與上面那種從作業單元中獲取倉儲的方法想法，它是往作業單元中提交，所以，我們此時可以構造出一個偽代碼出來，大致理解它的實作：

    //1、使用作業單元管理器創建一個作業單元
    using (var uow = unitOfWorkManager.Create())
    {
        //2、構造事務特征物件，開啟事務并注冊到作業單元
        RegisteTransactonFeature(DbContext);
        //3、執行倉儲中的內容
        DbContext.Set<Itinerary>().Add(itinerary)
        //4、作業單元保存提交
        uow.SaveChanges();
        //5、dispose
    }

至少到目前，我們可以抽象出上面的各個物件了，
您也可以先自己嘗試著想一想，每個物件介面應該實作什么功能（方法），

//首先是事務特征物件，它提供了事務的基本Commit和Rollback方法
public interface ITransactionFeature
{
    public bool IsCommit { get; }
    public bool IsRollback { get; }

    void Commit();
    Task CommitAsync(CancellationToken cancellationToken = default);
    void Rollback();
    Task RollbackAsync(CancellationToken cancellationToken = default);
}

//然后是事務特征容器，它具有增加洗掉事務特征物件的方法
public interface ITransactionFeatureContainer
{
    void RegisteTranasctionFeature(string key, ITransactionFeature TransactionFeature);
    ITransactionFeature GetOrAddTransactionFeature(string key, ITransactionFeature TransactionFeature);
    ITransactionFeature GetTransactionFeature(string key);
    void RemoveTransaction(string key);
}

//接下來是作業單元，它實作了事務特征容器，并且對外提供提交的方法
public interface IUnitOfWork : ITransactionFeatureContainer
{
    Guid ID { get; }
    bool IsDisposed { get; }

    void SaveChanges();
    Task SaveChangesAsync(CancellationToken cancellationToken = default);
    void Rollback();
    Task RollbackAsync(CancellationToken cancellationToken = default);
}

//最后是作業單元管理器，它提供了創建作業單元的方法
public interface IUnitOfWorkManager : IUnitOfWokrProvider, IDisposable
{
    IUnitOfWork Create();
}

落地代碼

在構建出介面之后，我們就可以寫出具體的實作類了，首先是實作作業單元（UnitOfWork）物件，（由于具體代碼實作較多，講解部分只選取了核心部分，完整代碼可以參考Github的專案）

public class UnitOfWork : IUnitOfWork
{
    private readonly Dictionary<string, ITransactionFeature> _transactionFeatures;

    public UnitOfWork()
    {
        _transactionFeatures = new Dictionary<string, ITransactionFeature>();
    }

    //往容器中添加事物特征物件
    public virtual ITransactionFeature GetOrAddTransactionFeature(
        [NotNull]string key,
        [NotNull] ITransactionFeature transcationFeature)
    {
        if (_transactionFeatures.ContainsKey(key))
            return _transactionFeatures.GetValueOrDefault(key);

        _transactionFeatures.Add(key, transcationFeature);
        return transcationFeature;
    }

    //對外提供的保存方法，執行該方法時呼叫容器內所有事物特征物件的Commit方法
    public virtual void SaveChanges()
    {
        foreach (var transactionFeature in _transactionFeatures.Values)
        {
            transactionFeature.Commit();
        }
    }
}

接下來就是與ORM框架關聯最深的事務特征物件的實作了，由于我們選取了EF，所以此處應該實作EF版本的事務特征物件：

public class EFTransactionFeature : ITransactionFeature
{
    private IDbContextTransaction _dbContextTransaction;
    private DbContext _dbContext;

    public EFTransactionFeature(DbContext dbContext)
    {
        _dbContext = dbContext;
    }

    //設定事務
    public void SetTransaction(IDbContextTransaction dbContextTransaction)
    {
        _isOpenTransaction = true;
        _dbContextTransaction = dbContextTransaction;
    }

    public void Commit()
    {
        if (IsCommit)
            return;

        IsCommit = true;

        //EF 事務的提交
        _dbContext.SaveChanges();
        _dbContextTransaction?.Commit();
    }
}

建立好了這兩個物件之后，其實我們只需要一個流轉程序就可以實作作業單元了，這個流程就是將事務特征物件添加到作業單元中，但是我們應該在什么時候將它添加進去呢？看過第一版Github代碼的小伙伴可能知道，在倉儲呼叫的時候就可以完成該操作，當時在第一版中，我們的實作代碼是這樣的：

public class EFRepository
{
    protected IUnitOfWorkManager UnitOfWorkManager { get; private set; }
    protected DbContext DbContext { get; private set; }

    public EFRepository(IUnitOfWorkManager unitOfWorkManager, DbContext dbContext)
    {
        UnitOfWorkManager = unitOfWorkManager;
        DbContext = dbContext;
    }

    public void Add(TAggregateRoot aggregateRoot)
    {
        RegistUnitOfWork(DbContext);

        DbContext.Set<TAggregateRoot>().Add(aggregateRoot);
    }

    private void RegistUnitOfWork(DbContext dbContext)
    {
        string key = $"EFTransactionFeature - {dbContext.ContextId.InstanceId.ToString()}";
        unitOfWork.ResigtedTransactionFeature(key, new EFTransactionFeature(DbContext));
    }
}

在每一次進行倉儲操作的時候，都呼叫了一個RegistUnitOfWork的方法，來完成事務特征物件和作業單元的流轉作業，但是很快您就能發現問題：EFRepository是我們實作的一個基類，以后所有的倉儲操作都繼承該類來完成操作，那不是每擴展一個方法，我都要在該方法中寫一句注冊代碼？如果我忘記寫了怎么辦，還有一點，該注冊程序并沒有開啟一個事務，那么事務是怎么來的呢？

那么怎么才能避免用戶每一次都要去顯示呼叫注冊呢，而是讓用戶在不知不覺中就完成了該操作，所以我們得思考在每一個方法中，用戶都一定會寫的代碼是什么，然后在該代碼上下手，可能您已經想到了，DbContext！！！是的，每一個方法里，用戶都會去寫DbContext，所以我們可以在他獲取DbContext的時候就完成注冊操作，所以，優化后的代碼就是這樣的：

public class EFRepository
{
    public virtual TDbContext DbContext
    {
        get => _dbContextFactory.CreateDbContext();
    }

    public void Add(TAggregateRoot aggregateRoot)
    {
        DbContext.Set<TAggregateRoot>().Add(aggregateRoot);
    }
}

而該_dbContextFactory的實作就更簡單了，他要完成的任務就是注冊到作業單元并且開啟事務，

internal class UowDbContextFactory<TDbContext>
{
    private readonly IUnitOfWorkManager _uowManager;

    public UowDbContextFactory(IUnitOfWorkManager uowManager)
    {
        _uowManager = uowManager;
    }

    public TDbContext CreateDbContext()
    {
        AddDbTransactionFeatureToUow(currentUow, DbContext);

        return wantedDbContext;
    }

    private void AddDbTransactionFeatureToUow(IUnitOfWork uow, TDbContext dbContext)
    {
        string key = $"EFCore - {dbContext.ContextId.InstanceId.ToString()}";
        var efFeature = uow.GetOrAddTransactionFeature(key, new EFTransactionFeature(dbContext));

        if (IsFeatureNeedOpenTransaction(uow, efFeature))
        {
            var dbcontextTransaction = dbContext.Database.BeginTransaction();
            efFeature.SetTransaction(dbcontextTransaction);
        }
    }

    private bool IsFeatureNeedOpenTransaction(IUnitOfWork uow, EFTransactionFeature efFeature)
    {
        return !efFeature.IsOpenTransaction;
    }
}

dbContext.Database.BeginTransaction是EF為我們提供的手動開啟事務的方法，如果您嘗試實作另外ORM版本的作業單元，想一下在該ORM中是怎么開啟的事務，

此時，我們就已經實作了作業單元的流轉了，那么還有一個問題就是：我們怎么默認去實作一個作業單元，而不是每一次都需要手動去開啟并提交，

AspNet Core為我們提供了很好的攔截方法，第一種方法： 我們可以在中間件中完成，因為所有的請求都要穿過中間件，我們可以在方法到API之前就開啟事務，等API訪問結束后就提交事務，第二種方法： 通過IActionFilter等周期介面來完成，本案例選取了第一種實作方法，您也可以根據您自己的愛好選取自己的實作方式，

缺陷

到這里我們已經實作了像上面Demo版本的作業單元，但是該作業單元其實還有許多特性沒有實作：

• 一個業務操作（一個API）中沒有創建多個作業單元的能力
• 目前事務的操作來源于EF Core的支持，如果專案存在多種資料訪問方式（比如一個EF，一個ADO），它們之間如何依靠作業單元來完成事務
• 沒有識別什么時候需要開啟作業單元，如果一個操作僅僅需要獲取資料，其實我們是不需要開啟作業單元的

不過如果您的專案僅僅使用了一種ORM框架并且只需要開啟一個作業單元，那么可以嘗試使用該實作，

在實作MiCake真正的作業單元中，我嘗試了很多方法來解決上面的問題，在后面的文章中，您也會看到MiCake真正的作業單元，

附上一個當時寫作業單元的手記（￣︶￣）↗

總結

本來這篇文章不打算寫在《如何運用領域驅動設計》這個系列的，但是后來糾結了一下，還是納入了該系列，由于該篇文章是實作作業單元的，所以代碼量就比較大，希望不會給您造成閱讀上的困難，下一篇的文章，是一個談了很久的問題————持久化值物件，現在終于是時候該解決它了，在本次Demo中您看到的聚合根Itinerary所有的屬性都是string，很顯然這是不符合常理的，所以在下一次就要讓它成為真正的領域物件，（ps:改成真正的領域物件后，感覺都可以單體DDD應用落地了呢，（￣︶￣）↗醒醒！少年，）為了您不錯過下一篇文章的內容，您也可也點擊博客園右上角的關注，這樣就能及時收到更新了喲，

標籤：.NET Core

上一篇：.NetCore集成Dapr踩坑經歷

下一篇：關于CRT初始化失敗有沒有大佬幫幫忙