1. 程式人生 > >如何運用領域驅動設計 - 工作單元

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

目錄

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

新年伊始,祝大家喜樂如意,愛和幸福“鼠”不盡!♫. ♪~♬.♩♫~

概述

在上一篇 《如何運用領域驅動設計 - 儲存庫》 的文章中,我們講述了有關倉儲的概念和使用規範。倉儲為聚合提供了持久化到本地的功能,但是在持久化的過程中,有時一個聚合根中的各個領域物件會分散到不同的資料庫表裡面;又或者是一個用例操作需要操作多個倉儲;而這些操作都應該要麼同時成功,要麼同時失敗,因此就需要為這一系列操作提供事務的支援,而事務管理就是由工作單元來提供的。在上一篇中,可能已經提到了工作單元,但是僅僅是一筆帶過,現在我們就來詳細的探究該如何更好的來實現工作單元。(文章的程式碼片段都使用的是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應用落地了呢。( ̄︶ ̄)↗醒醒!少年。)為了您不錯過下一篇文章的內容,您也可也點選部落格園右上角的關注,這樣就能及時收到更新了喲。