CQRS+ES專案解析01-Diary.CQRS

thz發表於2019-06-24

在《當我們在討論CQRS時，我們在討論些神馬》中，我們討論了當使用CQRS的過程中，需要關心的一些問題。其中與CQRS關聯最為緊密的模式莫過於Event Sourcing了，CQRS與ES的結合，為我們構造高效能、可擴充套件系統提供了基本思路。本文將介紹
Kanasz Robert在《Introduction to CQRS》中的示例專案Diary.CQRS。

獲取Diary.CQRS專案

該專案為Kanasz Robert為了介紹CQRS模式而寫的一個測試專案，原始專案可以通過訪問《Introduction to CQRS》來獲取，由於專案版本比較舊，沒有使用nuget管理程式包等，導致下載以後並不能正常執行，我下載了這個專案，升級到Visual Studio 2017，重新引用了StructMap框架（使用nuget），移除了Web層報錯的程式碼，並上傳到部落格園，可以從這裡下載：Diary.CQRS.rar

Diary.CQRS專案簡介

Diary.CQRS專案的場景為日記本管理，提供了新增、編輯、刪除、列表等功能，整個解決方案分為三個專案：

Diary.CQRS：核心專案，完成了EventBus、CommandBus、Domain、Storage等功能，也是我們分析的重點。
Diary.CQRS.Configuration：服務配置，通過ServiceLocator類進行依賴注入、服務查詢功能。
Diary.CQRS.Web：使用者介面，MVC專案。

這是一個很好的入門專案，功能簡單、結構清晰，概念覆蓋全面。如果CQRS是一個城堡，那麼Diary.CQRS則是開啟第一重門的鑰匙，接下來讓我們一起推開這扇門吧。

Diary.CQRS.Web

執行專案，最先看到的是一個Web頁面，如下圖：

很簡單，只有一個Add按鈕，當我們點選以後，會進入新增的頁面：

我們填上一些內容，然後點選Save按鈕，就會返回到列表頁，我們可以看到已新增的條目：

然後我們進行編輯操作，點選列表中的Edit按鈕，跳轉到編輯頁面：

雖然頁面中顯示的是Add，但確實是Edit頁面。我們編輯以後點選Save按鈕，然後返回列表頁即可看到編輯後的內容。

在列表頁中，如果我們點選Delete按鈕，則會刪除改條目。

到此為止，我們已經看到了這個專案的所有頁面，一個簡單的CURD操作。我們繼續看它的程式碼（在HomeController中）。

Index：列表頁面

public ActionResult Index()
{
    ViewBag.Model = ServiceLocator.ReportDatabase.GetItems();
    return View();
}

通過ServiceLocator定位ReportDatabase，並從ReportDatabase中獲取所有條目。

Add：新增頁面

public ActionResult Add()
{
    return View();
}

[HttpPost]
public ActionResult Add(DiaryItemDto item)
{
    ServiceLocator.CommandBus.Send(new CreateItemCommand(Guid.NewGuid(), item.Title, item.Description, -1, item.From, item.To));
    return RedirectToAction("Index");
}

兩個方法：

Add()方法，處理Get請求，返回新增檢視；
Add(DiaryItemDto item)方法，接收DiaryItemDto引數，處理Post請求，建立併傳送CreateItemCommand命令，然後返回到Index頁面

Edit：編輯頁面

public ActionResult Edit(Guid id)
{
    var item = ServiceLocator.ReportDatabase.GetById(id);
    var model = new DiaryItemDto()
    {
        Description = item.Description,
        From = item.From,
        Id = item.Id,
        Title = item.Title,
        To = item.To,
        Version = item.Version
    };
    return View(model);
}

[HttpPost]
public ActionResult Edit(DiaryItemDto item)
{
    ServiceLocator.CommandBus.Send(new ChangeItemCommand(item.Id, item.Title, item.Description, item.From, item.To, item.Version));
    return RedirectToAction("Index");
}

仍然是兩個方法：

Edit(Guid id)方法，接收Guid作為引數，並從ReportDatabase中獲取資料，構建dto物件返回給頁面
Edit(DiaryItemDto item)方法，接收DiaryItemDto物件，處理Post請求，接收到請求以後根據dto物件建立ChangeItemCommand命令，然後返回到Index頁面

Delete：刪除操作

public ActionResult Delete(Guid id)
{
    var item = ServiceLocator.ReportDatabase.GetById(id);
    ServiceLocator.CommandBus.Send(new DeleteItemCommand(item.Id, item.Version));
    return RedirectToAction("Index");
}

對於刪除操作來說，它沒有檢視頁面，接收到請求以後，先獲取該記錄，建立併傳送DeleteImteCommand命令，然後返回到Index頁面

題外話：對於改變資料狀態的操作，使用Get請求是不可取的，可能存在安全隱患

通過上面的程式碼，你會發現所有的操作都是從ServiceLocator發起的，通過它我們能夠定位到CommandBus和ReportDatabase，從而進行相應的操作，我們在接下來會介紹ServiceLocator類。

Diary.CQRS.Configuration

Diary.CQRS.Configuration 專案中定義了ServiceLocator類，這個類的作用是完成IoC容器的服務註冊、服務定位功能。例如我們可以通過ServiceLocator獲取到CommandBus例項、獲取ReportDatabase例項。

服務註冊

ServiceLocator使用StructureMap作為依賴注入框架，提供了服務註冊、服務導航的功能。ServiceLocator類通過靜態建構函式完成對服務註冊和服務例項化工作：

static ServiceLocator()
{
    if (!_isInitialized)
    {
        lock (_lockThis)
        {
            ContainerBootstrapper.BootstrapStructureMap();
            _commandBus = ObjectFactory.GetInstance<ICommandBus>();
            _reportDatabase = ObjectFactory.GetInstance<IReportDatabase>();
            _isInitialized = true;
        }
    }
}

首先呼叫ContainerBootstrapper.BootstrapStructureMap()方法，這個方法裡面包含了對將服務新增到容器的程式碼；然後使用容器建立CommandBus和ReportDatabase的例項。

CommandBus：命令匯流排，對應Command操作，用來傳送命令，程式中需要定義相應的命令處理器，從而完成具體的操作。
ReportDatabase：報表資料庫，對應Query操作，用來獲取資料。

ServiceLocator的重要之處在於對外暴露了兩個至關重要的例項，分別處理CQRS中的Command和Query。

為什麼沒有Event相關操作呢？到目前為止我們還沒有涉及到，因為對於UI層來說，使用者的意圖都是通過Command表示的，而資料的狀態變化才會觸發Event。

Diary.CQRS

在ServiceLocator中定義了獲取CommandBus和ReportDatabase的方法，我們順著這兩個物件繼續分析。

CommandBus

在基於訊息的系統設計中，我們常會看到匯流排的身影，Command也是一種訊息，所以使用匯流排是再合適不過的了。CommandBus就是我們在Diary.CQRS專案中用到的一種訊息匯流排。

在Diary.CQRS中，它被定義在Messaging目錄，在這個目錄下面，還有與Event相關的EventBus，我們稍後再進行介紹。

CommandBus實現ICommandBus介面，ICommandBus介面的定義如下：

public interface ICommandBus
{
    void Send<T>(T command) where T : Command;
}

它只包含了Send方法，用來將命令傳送到對應的處理程式。

CommandBus是ICommand的實現，具體程式碼如下：

public class CommandBus:ICommandBus
{
    private readonly ICommandHandlerFactory _commandHandlerFactory;

    public CommandBus(ICommandHandlerFactory commandHandlerFactory)
    {
        _commandHandlerFactory = commandHandlerFactory;
    }

    public void Send<T>(T command) where T : Command
    {
        var handler = _commandHandlerFactory.GetHandler<T>();
        if (handler!=null)
        {
            handler.Execute(command);
        }
        else
        {
            throw new Exception();
        }
    }
}

在CommandBus中，顯式依賴ICommandHandlerFactory類，通過建構函式進行注入。那麼 _commandHandlerFactory 的作用是什麼呢？我們在Send方法中可以看到，通過 _commandHandlerFactory 可以獲取到與Command對應的CommandHandler（命令處理程式），在程式的設計上，每一個Command都會有一個對應的CommandHandler，而手工判斷型別、例項化處理程式顯然不符合使用習慣，此處採用工廠模式來獲取命令處理程式。

當獲取到與Command對應的CommandHandler後，呼叫handler的Execute方法，執行該命令。

截止目前為止，我們又接觸了三個概念：CommandHandlerFactory、CommandHandler、Command：

CommandHandlerFactory：命令處理程式工廠，通過GetHandler方法獲取到與命令對應的處理程式
CommandHandler：命令處理程式，用於執行對應的命令
Command：命令，描述使用者的意圖、幷包含與意圖相關的資料

CommandHandlerFactory

使用簡單工廠模式，用來獲取與命令對應的處理程式。它的程式碼在Utils資料夾中，它的作用是提供一種獲取Handler的方式，所以它只能作為工具存在。

介面定義如下：

public interface ICommandHandlerFactory
{
    ICommandHandler<T> GetHandler<T>() where T : Command;
}

只有GetHandler一個方法，它的實現是 StructureMapCommandHandlerFactory，即通過StructureMap作為依賴注入框架來實現的，程式碼也比較簡單，這裡不再貼出來了。

Command和CommandHandler

命令是代表使用者的意圖、幷包含與意圖相關的資料，比如使用者想要新增一條資料，這便是一個意圖，於是就有了CreateItemCommand，使用者要在介面上填寫新增操作必須的資料，於是就有了命令的屬性。

關於命令的定義如下：

public interface ICommand
{
    Guid Id { get; }
}

public class Command : ICommand
{
    public Guid Id { get; private set; }
    public int Version { get; set; }

    public Command(Guid id, int version)
    {
        Id = id;
        Version = version;
    }
}

ICommand介面：包含Id屬性，這個Id表示Command對應聚合的Id。聚合是領域驅動開發（DDD）的概念，表示一組強關聯的領域物件，而對聚合中狀態的變更，只能通過聚合根（AggregateRoot）來完成。
Command類：實現了ICommand介面，並增加了Version屬性，用來標記當前操作對應的聚合跟的版本。

為什麼要有版本的概念的？因為當使用ES模式的時候，資料庫中的資料都是事件產生的資料映象，儲存了某個時間點的資料快照，如果要獲取到最新的資料，則需要通過載入該聚合根對應的所有Event來回放到最新狀態。如果引入版本的概念，每一個Event對應一個版本，而景象中的資料也有一個版本，在進行回放的時候，可以僅載入高版本的Event進行回放，節省了系統資源，並提高了執行效率。

命令處理程式，它的作用是處理與它相對應的命令，處理CQRS的核心，介面定義如下：

public interface ICommandHandler<TCommand> where TCommand : Command
{
    void Execute(TCommand command);
}

它接收command作為引數，執行該命令的處理邏輯。每一個命令都有一個與之對應的處理程式。

我們再重新梳理一下流程，首先使用者要新增一個資料，點選儲存按鈕後，生成CreateItemCommand命令，隨後這個命令被髮送到CommandBus中，CommandBus通過CommandHandlerFactory找到該Command的處理程式，此時在CommandBus的Send方法中，我們有一個Command和CommandHandler，然後呼叫CommandHandler的Execute方法，即完成了該方法的處理。至此，Command的處理流程完結。

CreateItemCommand和CreateItemCommandHandler

我們來看一下CreateItemCommand的程式碼：

public class CreateItemCommand : Command
{
    public string Title { get; internal set; }
    public string Description { get; internal set; }
    public DateTime From { get; internal set; }
    public DateTime To { get; internal set; }

    public CreateItemCommand(Guid aggregateId, string title,
        string description, int version, DateTime from, DateTime to)
        : base(aggregateId, version)
    {
        Title = title;
        Description = description;
        From = from;
        To = to;
    }
}

它繼承自Command基類，繼承後即擁有了Id和Version屬性，然後又定義了幾個其它的屬性。它只包含資料，與該命令對應的處理程式叫做CreateItemCommandHandler，程式碼如下：

public class CreateItemCommandHandler : ICommandHandler<CreateItemCommand>
{
    private IRepository<DiaryItem> _repository;

    public CreateItemCommandHandler(IRepository<DiaryItem> repository)
    {
        _repository = repository;
    }

    public void Execute(CreateItemCommand command)
    {
        if (command == null)
        {
            throw new Exception();
        }
        if (_repository == null)
        {
            throw new Exception();
        }
        var aggregate = new DiaryItem(command.Id, command.Title, command.Description, command.From, command.To);
        aggregate.Version = -1;
        _repository.Save(aggregate, aggregate.Version);
    }
}

這才是我們要分析的核心，在Handler中，我們看到了Repository，看到了DiaryItem聚合：

IRepository：倉儲類，代表資料的儲存方式，通過倉儲能夠進行資料操作
DiaryItem：領域物件，聚合根，所有資料狀態的變更只能通過聚合根來修改

在上面的程式碼中，由於是新增，所以聚合的版本為-1，然後呼叫倉儲的Save方法進行儲存。我們繼續往下扒，看看倉儲和聚合的實現。

Repository

對於Repository的定義，仍然先看一下介面中的定義，程式碼如下：

public interface IRepository<T> where T : AggregateRoot, new()
{
    void Save(AggregateRoot aggregate, int expectedVersion);
    T GetById(Guid id);
}

在倉儲中只有兩個方法：

Save(AggregateRoot aggregate, int expectedVersion)：儲存期望版本的聚合根
GetById(Guid id)：根據聚合根Id獲取聚合根

關於IRepository的實現，程式碼在Repository.cs中，我們拆開來進行介紹：

private readonly IEventStorage _eventStorage;
private static object _lock = new object();

public Repository(IEventStorage eventStorage)
{
    _eventStorage = eventStorage;
}

首先是它的建構函式，強依賴IEventStorage，通過建構函式注入。EventStorage是事件的儲存倉庫，有個更為熟知的名字EventStore，我們稍後進行介紹。

public T GetById(Guid id)
{
    IEnumerable<Event> events;
    var memento = _eventStorage.GetMemento<BaseMemento>(id);
    if (memento != null)
    {
        events = _eventStorage.GetEvents(id).Where(e => e.Version >= memento.Version);
    }
    else
    {
        events = _eventStorage.GetEvents(id);
    }
    var obj = new T();
    if (memento != null)
    {
        ((IOriginator)obj).SetMemento(memento);
    }
    obj.LoadsFromHistory(events);
    return obj;
}

GetById(Guid id)方法通過Id獲取一個聚合物件，獲取一個聚合物件有以下幾個步驟：

首先會從EventStorage中獲取到該聚合的快照（memento的翻譯為記憶碎片、紀念品、備忘錄，用來聚合物件的快照）。
載入Event列表，載入到的事件列表將用來做事件回放。

如果獲取到快照的話，則載入版本高於該快照版本的事件列表，如果沒有獲取到快照，則載入全部事件列表。此處在上面已經介紹過，通過快照的方式儲存聚合物件，在獲取資料時可以減少重放事件的數量，起到提高載入速度的作用。
例項化聚合根，對應程式碼中的var obj = new T();。
從快照中設定聚合根的狀態。在獲取到快照以後，如果快照不為空，則呼叫聚合根的SetMemento方法設定為快照中的狀態，SetMemento方法定義在IOriginator介面中，聚合根需要實現該介面。
載入歷史事件，完成重放。完成這個步驟以後，聚合根將更新到最新狀態。

通過這幾個步驟以後，我們得到了一個最新狀態的聚合根物件。

public void Save(AggregateRoot aggregate, int expectedVersion)
{
    if (aggregate.GetUncommittedChanges().Any())
    {
        lock (_lock)
        {
            var item = new T();
            if (expectedVersion != -1)
            {
                item = GetById(aggregate.Id);
                if (item.Version != expectedVersion)
                {
                    throw new Exception();
                }
            }
            _eventStorage.Save(aggregate);
        }
    }
}

Save方法，用來儲存一個聚合根物件。在這個方法中，引數expectedVersion表示期望的版本，這裡約定-1為新增的聚合根，當聚合根為新增的時候，會直接呼叫EventStorage中的Save方法。

關於expectedVersion引數，我們可以理解為對併發的控制，只有當expectedVersion與GetById獲取到的聚合根物件的版本相同時才能進行儲存操作。

在介紹Repository類的時候，我們接觸了兩個新的概念：EventStorage和AggregateRoot，接下來我們分別進行介紹。

AggregateRoot

AggregateRoot是聚合根，他表示一組強關聯的領域物件，所有物件的狀態變更只能通過聚合根來完成，這樣可以保證資料的一致性，以及減少併發衝突。應用到EventSourcing模式中，聚合根的好處也是很明顯的，我們所有對資料狀態的變更都通過聚合根完成，而每次變更，聚合根都會生成相應的事件，在進行事件回放的時候，又通過聚合根來完成歷史事件的載入。由此我們可以看到，聚合根物件應該具備生成事件、重放事件的能力。

我們來看看聚合根基類的定義，在Domain資料夾中：

public abstract class AggregateRoot : IEventProvider{
    // ......
}

首先這是一個抽象類，實現了IEventProvider介面，該介面的定義如下：

public interface IEventProvider
{
    void LoadsFromHistory(IEnumerable<Event> history);
    IEnumerable<Event> GetUncommittedChanges();
}

它定義了兩個方法，我們分別進行說明：

LoadsFromHistory()方法：載入歷史事件，還原聚合根的最新狀態，我們在Repository中已經用過這個方法。
GetUncommittedChanges()方法：獲取未提交的事件。一個命令可能造成聚合根發生多次更改，每次更改都會產生一個事件，這些事件被暫時的儲存在聚合根物件中，通過該方法可以獲取到未提交的事件列表。

為了實現這個介面，聚合根中定義了 List<Event> _changes物件，用來臨時儲存所有未提交的事件，該物件在建構函式中進行初始化。

AggregateRoot中對於該事件的實現如下：

public void LoadsFromHistory(IEnumerable<Event> history)
{
    foreach (var e in history)
    {
        ApplyChange(e, false);
    }
    Version = history.Last().Version;
    EventVersion = Version;
}

public IEnumerable<Event> GetUncommittedChanges()
{
    return _changes;
}

LoadsFromHistory方法遍歷歷史事件，並呼叫ApplyChange方法更新聚合根的狀態，在完成更新後設定版本號為最後一個事件的版本。GetUncommittedChanges方法比較簡單，返回物件的_changes事件列表。

接下來我們看看ApplyChange方法，該方法有兩個實現，程式碼如下：

protected void ApplyChange(Event @event)
{
    ApplyChange(@event, true);
}

protected void ApplyChange(Event @event, bool isNew)
{
    dynamic d = this;
    d.Handle(Converter.ChangeTo(@event, @event.GetType()));
    if (isNew)
    {
        _changes.Add(@event);
    }
}

這兩個方法定義為protected，只能被子類訪問。我們可以理解為，ApplyChange(Event @event)方法為簡化操作，對第二個引數進行了預設為true的操作，然後呼叫ApplyChange(Event @event, bool isNew)方法。

在ApplyChange(Event @event, bool isNew)方法中，呼叫了聚合根的Handle方法，用來處理事件。如果isNew引數為true，則將事件新增到change列表中，如果為false，則認為是在進行事件回放，所以不進行事件的新增。

需要注意的是，聚合根的Handle方法，與EventHandler不同，當Event產生以後，首先由它對應的聚合根進行處理，因此聚合根要具備處理該事件的能力，如何具備呢？聚合根要實現IHandle介面，該介面的定義如下：

public interface IHandle<TEvent> where TEvent:Event
{
    void Handle(TEvent e);
}

這裡可以看出，IHandle介面是泛型的，它只對一個具體的Event型別生效，在程式碼上的體現如下：

public class DiaryItem : AggregateRoot,
    IHandle<ItemCreatedEvent>,
    IHandle<ItemRenamedEvent>,
    IHandle<ItemFromChangedEvent>,
    IHandle<ItemToChangedEvent>,
    IHandle<ItemDescriptionChangedEvent>,
    IOriginator
{
    //......
}

最後，聚合根還定義了清除所有事件的方法，程式碼如下：

public void MarkChangesAsCommitted()
{
    _changes.Clear();
}

MarkChangesAsCommitted()方法用來清空事件列表。

Event

終於到我們今天的另外一個核心內容了，Event是ES中的一等公民，所有的狀態變更最終都以Event的形式進行儲存，當我們要檢視聚合根最新狀態的時候，可以通過事件回放來獲取。我們來看看Event的定義：

public interface IEvent
{
    Guid Id { get; }
}

IEvent介面定義了一個事件必須擁有唯一的Id進行標識。然後Event實現了IEvent介面：

public class Event:IEvent
{
    public int Version;
    public Guid AggregateId { get; set; }
    public Guid Id { get; private set; }
}

可以看到，除了Id屬性外，還新增了兩個欄位Version和AggregateId。AggregateId表示該事件關聯的聚合根Id，通過該Id可以獲取到唯一的聚合根物件；Version表示事件發生時該事件的版本，每次產生新的事件，Version都會進行累加。

從而可以知道，在EventStorage中，聚合根Id對應的所有Event中的Version是順序累加的，按照Version進行排序可以得到事件發生的先後順序。

EventStorage

顧名思義，EventStorage是用來儲存Event的地方。在Diary.CQRS中，EventStorage的定義如下：

public interface IEventStorage
{
    IEnumerable<Event> GetEvents(Guid aggregateId);
    void Save(AggregateRoot aggregate);
    T GetMemento<T>(Guid aggregateId) where T : BaseMemento;
    void SaveMemento(BaseMemento memento);
}

GetEvents(Guid aggregateId)：根據聚合根Id獲取該聚合根的所有事件
Save(AggregateRoot aggregate)：儲存方法，入參為聚合根物件，在實現上則是獲取聚合根中所有未提交的事件，隨後對這些事件進行處理
GetMemento()：獲取快照
SaveMemento()：儲存快照

Diary.CQRS中使用InMemory的方式實現了EventStorage，屬性和建構函式如下：

private List<Event> _events;
private List<BaseMemento> _mementoes;
private readonly IEventBus _eventBus;

public InMemoryEventStorage(IEventBus eventBus)
{
    _events = new List<Event>();
    _mementoes = new List<BaseMemento>();
    _eventBus = eventBus;
}

_events：事件列表，記憶體中儲存事件的位置，所有事件最終都會儲存在該列表中
_mementoes：快照列表，用於儲存聚合根的某個事件版本的狀態
_eventBus：事件匯流排，用於釋出任務

當Event生成後，它並沒有馬上存入EventStorage，而是在Repository顯示呼叫Save方法時，倉儲將儲存權交給了EventStorage，EventStorage是事件倉庫，事件倉儲在儲存時進行了如下操作：

獲取聚合根中所有未提交的Event，同時獲取到聚合根當前的版本號
遍歷未提交Event列表，根據聚合根版本號自動為Event生成版本號，保持自增長的特性；
生成聚合根快照。示例中每3個版本生成一次，並保持到事件倉儲中。
將任務新增到事件倉庫中。
再次遍歷未提交Event列表，此時將進行任務釋出，呼叫事件匯流排的Publish方法進行釋出。

Save方法的程式碼如下：

public void Save(AggregateRoot aggregate)
{
    var uncommittedChanges = aggregate.GetUncommittedChanges();
    var version = aggregate.Version;

    foreach (var @event in uncommittedChanges)
    {
        version++;
        if (version > 2)
        {
            if (version % 3 == 0)
            {
                var originator = (IOriginator)aggregate;
                var memento = originator.GetMemento();
                memento.Version = version;
                SaveMemento(memento);
            }
        }
        @event.Version = version;
        _events.Add(@event);
    }
    foreach (var @event in uncommittedChanges)
    {
        var desEvent = Converter.ChangeTo(@event, @event.GetType());
        _eventBus.Publish(desEvent);
    }
}

至此Event的處理流程就算完結了。此時所有的操作都是在主庫完成的，當事件被髮布以後，訂閱了該事件的所有Handler都將會被觸發。

在Diary.CQRS專案中，EventHandler都被用來處理ReportDatabase了。

ReportDatabase

當你使用ES模式時，都存在一個嚴重問題，那就是資料查詢的問題。當使用者進行資料檢索是，必然會使用各種查詢條件，然而無論那種事件倉庫都很難滿足複雜查詢。為了解決此問題，ReportDatabase就顯得格外重要。

ReportDatabase的作用被定義為獲取資料、應對資料查詢、生成報表等，它的結構與主庫不同，可以根據不同的業務場景進行定義。

ReportDatabase的資料不是通過業務邏輯進行更新的，它通過訂閱Event進行更新。在本示例中ReportDatabase實現的很簡單，介面定義如下：

public interface IReportDatabase
{
    DiaryItemDto GetById(Guid id);
    void Add(DiaryItemDto item);
    void Delete(Guid id);
    List<DiaryItemDto> GetItems();
}

實現上，通過記憶體中維護一個列表，每次接收到事件以後，都對相應資料進行更新，此處不在貼出。

EventHandler、EventHandlerFactory和EventBus

在上文中已經介紹過Event，而針對Event的處理，實現邏輯上與Command非常相似，唯一的區別是，命令只可以有一個對應的處理程式，而事件則可以有多個處理程式。所以在EventHandlerFactory中獲取處理程式的方法返回了EventHandler列表，程式碼如下：

public IEnumerable<IEventHandler<T>> GetHandlers<T>() where T : Event
{
    var handlers = GetHandlerType<T>();

    var lstHandlers = handlers.Select(handler => (IEventHandler<T>)ObjectFactory.GetInstance(handler)).ToList();
    return lstHandlers;
}

在EventBus中，如果一個事件沒有處理程式也不會引發錯誤，如果有一個或多個處理程式，則會以此呼叫他們的Handle方法，程式碼如下：

public void Publish<T>(T @event) where T : Event
{
    var handlers = _eventHandlerFactory.GetHandlers<T>();
    foreach (var eventHandler in handlers)
    {
        eventHandler.Handle(@event);
    }
}

總結

Diary.CQRS是一個典型的CQRS+ES演示專案，通過對該專案的分析，我們能瞭解到Command、AggregateRoot、Event、EventStorage、ReportDatabase的基礎知識，瞭解他們相互關係，尤其是如何進行事件儲存、如何進行事件回放的內容。

另外，我們發現在使用CQRS+ES的過程中，專案的複雜度增加了很多，我們不可避免的要使用EventStore、Messaging等架構，從而影響那些不瞭解CQRS的團隊成員的加入，因此在應用到實際專案的時候，要適可而止，慎重選擇，避免過度設計。

由於這是一個示例，專案程式碼中存在很多不夠嚴謹的地方，大家在學習的過程中應進行甄別。

由於本人的知識有限，如果內容中存在不準確或錯誤的地方，還請不吝賜教！

解析軟體專案管理(轉)
2007-08-14
專案管理
vue（16）vue-cli建立專案以及專案結構解析
2021-07-15
Vue
專案管理軟體功能全解析
2020-04-13
專案管理
Ant Design Vue專案解析-前言
2019-05-22
Vue
玄學野路子專案，探秘解析
2024-05-03
Avalonia開發（二）專案結構解析
2023-09-20
Android 開源專案原始碼解析 -->PhotoView 原始碼解析(七)
2016-09-27
Android原始碼View
ApkTool專案解析resources.arsc詳解
2018-05-01
APK
Android專案的依賴關係解析
2015-03-23
Android
Android 開源專案原始碼解析 -->Volley 原始碼解析(十五)
2016-09-27
Android原始碼
Android 開源專案原始碼解析 -->Dagger 原始碼解析(十三)
2016-09-27
Android原始碼
2018微博詞雲專案深度解析
2019-01-04
解析：APP拉新充場專案的玩法思路
2021-09-30
APP
java專案部署異常解析及處理方案
2018-01-04
Java
MVP+Retrofit+Rxjava在專案中實戰解析
2017-07-19
MVPRxJava
iOS專案開發實戰——plist陣列解析
2015-08-19
iOS陣列
Android 開源專案原始碼解析 -->CircularFloatingActionMenu 原始碼解析(八)
2016-09-27
Android原始碼
檔案解析，在mysql配置和檢查項一樣的專案
2020-11-29
MySql
低程式碼專案建設常見問題解析
2023-11-02
Flutter入門教程（四）第一個flutter專案解析
2022-04-01
Flutter
智慧合約開發dapp專案解析（原始碼）
2023-02-06
APP原始碼
ionic 2.x 3.x專案結構解析
2017-08-16
Myth原始碼解析系列之一-專案簡介
2018-01-15
原始碼
Vue小白課（二）——專案結構解析（Vue2.x）
2019-01-15
Vue
MyBatis第四章：專案案例mybatis主要配置解析
2020-12-20
MyBatis
看板管理解析：如何透過看板提升專案管理效率？
2023-05-19
專案管理
推進產品研發專案成功：管理要點解析
2023-05-10
§1.2 Android專案結構及“Hello World”應用解析
2016-10-14
Android
Nginx路由到不同埠的beego專案地址解析失敗
2017-06-11
Nginx路由Go
vue專案PC端如何適配不同解析度螢幕
2023-03-05
Vue
元宇宙遊戲專案系統開發模式功能方案解析
2023-02-10
元宇宙遊戲模式
Myth原始碼解析系列之二-專案結構介紹
2018-01-15
原始碼
從燃盡圖看專案管理：你的專案哪裡出錯了？(燃盡圖型別全解析）
2018-08-01
專案管理型別
XML 檔案解析實踐 (DOM 解析)
2020-10-02
XML
eml檔案解析
2020-12-18
Class檔案解析
2022-11-29
鴻蒙系統系列教程6-鴻蒙系統專案結構解析
2021-07-14
鴻蒙
Android Studio目錄結構及工程專案結構解析
2018-12-11
Android