從壹開始微服務 [ DDD ] 之十二 ║ 核心篇【下】：事件驅動EDA 詳解

1、一個是命令提交的的事務比較長，效能會有問題，甚至在極端情況下容易引發資料庫的嚴重故障（伺服器方面）；
2、另外提交的服務內聚性差，可維護性差，在業務流程發生變更時候，需要頻繁修改主程式（程式設計師方面）。
3、我們有時候只關心核心的流程，就比如新增Student，我們只關心是否新增成功，而且我們需要對這個成功有反饋，但是發郵件的功能，我們卻不用放在主業務中，甚至傳送成功與否，不影響 Student 的正常新增，這樣我們就把後續的這些活動事件，從主業務中剝離開，實現了高內聚和低耦合（業務方面）。

還記得 MediatR 有兩個中介者模式麼：請求/響應 和 釋出/訂閱。在我們的系統中，新增一個學生命令，就是用到的請求/響應 IRequest 模式，因為我們需要等待當前操作完成，我們需要匯流排對我們的請求做出響應。

但是有時候我們不需要在同一請求/響應中立即執行一個動作的結果，只要非同步執行這個動作，比如傳送電子郵件。在這種情況下，我們使用釋出/訂閱模式，以非同步方式傳送電子郵件，並避免讓使用者等待發送電子郵件。

4、領域事件驅動是如何執行的呢？

這個時候，就用到之前我畫的圖了，中介者模式下，上半部的命令匯流排已經說完，今天說另一半事件匯流排：

當然這裡也有一個網上的栗子，很不錯：

從圖中我們也可以看到，事件驅動的工作流程呢，在命令模式下，主要是在我們的命令處理程式中出現，在我們對資料進行持久化操作的時候，作為一個後續活動事件來存在，比如我們今天要實現的兩個處理工作：

1、通知資訊的收集（之前我們是採用的快取 Memory 來實現的）；
2、領域通知處理程式（比如發郵件等）；

這個時候，如果你對事件驅動有了一定的理解的話，你就會問，那我們在專案中具體的應該使用呢，請往下看。

二、建立事件匯流排

這個整體流程其實和命令匯流排分發很像，所以原理就不分析了，相信你如果看了之前的兩篇文章的話，一定能看懂今天的內容的。

1、定義領域事件標識基類

就如上邊我們說到的，我們可以定義一個介面，也可以定義一個抽象類，我比較習慣用抽象類，在核心領域層 Christ3D.Domain.Core 中的Events 資料夾中，新建Event.cs 事件基類：

namespace Christ3D.Domain.Core.Events
{
/// <summary>
/// 事件模型 抽象基類，繼承 INotification
/// 也就是說，擁有中介者模式中的 釋出/訂閱模式
/// </summary>
public abstract class Event : INotification
{
// 時間戳
public DateTime Timestamp { get; private set; }

// 每一個事件都是有狀態的
protected Event()
{
Timestamp = DateTime.Now;
}
}
}

2、定義事件匯流排介面

在中介處理介面IMediatorHandler中，定義引發事件介面，作為釋出者，完整的 IMediatorHandler.cs 應該是這樣的

namespace Christ3D.Domain.Core.Bus
{
/// <summary>
/// 中介處理程式介面
/// 可以定義多個處理程式
/// 是非同步的
/// </summary>
public interface IMediatorHandler
{
/// <summary>
/// 傳送命令，將我們的命令模型釋出到中介者模組
/// </summary>
/// <typeparam name="T"> 泛型 </typeparam>
/// <param name="command"> 命令模型，比如RegisterStudentCommand </param>
/// <returns></returns>
Task SendCommand<T>(T command) where T : Command;

/// <summary>
/// 引發事件，通過匯流排，釋出事件
/// </summary>
/// <typeparam name="T"> 泛型 繼承 Event：INotification</typeparam>
/// <param name="event"> 事件模型，比如StudentRegisteredEvent，</param>
/// 請注意一個細節：這個命名方法和Command不一樣，一個是RegisterStudentCommand註冊學生命令之前,一個是StudentRegisteredEvent學生被註冊事件之後
/// <returns></returns>
Task RaiseEvent<T>(T @event) where T : Event;

}
}

3、實現匯流排分發介面

在基層設施匯流排層 Christ3D.Infra.Bus 的記憶匯流排 InMemoryBus.cs 中，實現我們上邊的事件分發匯流排介面：

 /// <summary>
 /// 引發事件的實現方法
 /// </summary>
 /// <typeparam name="T">泛型 繼承 Event：INotification</typeparam>
 /// <param name="event">事件模型，比如StudentRegisteredEvent</param>
 /// <returns></returns>
 public Task RaiseEvent<T>(T @event) where T : Event
 {
// MediatR中介者模式中的第二種方法，釋出/訂閱模式
return _mediator.Publish(@event);
 }

注意這裡使用的是中介模式的第二種——釋出/訂閱模式，想必這個時候就不用給大家解釋為什麼要使用這個模式了吧（提示：不需要對請求進行必要的響應，與請求/響應模式做對比思考）。現在我們把事件匯流排定義（是一個釋出者）好了，下一步就是如何定義事件模型和處理程式了也就是訂閱者，如果上邊的都看懂了，請繼續往下走。

三、事件模型的處理與使用

可能這句話不是很好理解，那說人話就是：我們之前每一個領域模型都會有不同的命令，那每一個命令執行完成，都會有對應的後續事件（比如註冊和刪除使用者肯定是不一樣的），當然這個是看具體的業務而定，就比如我們的訂單領域模型，主要的有下單、取消訂單、刪除訂單等。

我個人感覺，每一個命令模型都會有對應的事件模型，而且一個命令處理方法可能有多個事件方法。具體的請看：

1、定義新增Student 的事件模型

當然還會有刪除和更新的事件模型，這裡就用新增作為栗子，在領域層 Christ3D.Domain 中，新建  Events 資料夾，用來存放我們所有的事件模型，

因為是 Student 模型，所以我們在 Events 資料夾下，新建 Student 資料夾，並新建 StudentRegisteredEvent.cs 學生新增事件類：

namespace Christ3D.Domain.Events
{
/// <summary>
/// Student被新增後引發事件
/// 繼承事件基類標識
/// </summary>
public class StudentRegisteredEvent : Event
{
// 建構函式初始化，整體事件是一個值物件
public StudentRegisteredEvent(Guid id, string name, string email, DateTime birthDate, string phone)
{
Id = id;
Name = name;
Email = email;
BirthDate = birthDate;
Phone = phone;
}
public Guid Id { get; set; }
public string Name { get; private set; }
public string Email { get; private set; }
public DateTime BirthDate { get; private set; }
public string Phone { get; private set; }
}
}

2、定義領域事件的處理程式Handler

這個和我們的命令處理程式一樣，只不過我們的 命令處理程式 是匯流排在 應用服務層 分發的，而 事件處理程式 是在 領域層的命令處理程式 中被匯流排引發的，可能有點兒拗口，看看下邊程式碼就清楚了，就是一個引用場景的順序問題。

namespace Christ3D.Domain.EventHandlers
{
/// <summary>
/// Student事件處理程式
/// 繼承INotificationHandler<T>，可以同時處理多個不同的事件模型
/// </summary>
public class StudentEventHandler :
INotificationHandler<StudentRegisteredEvent>,
INotificationHandler<StudentUpdatedEvent>,
INotificationHandler<StudentRemovedEvent>
{
// 學習被註冊成功後的事件處理方法
public Task Handle(StudentRegisteredEvent message, CancellationToken cancellationToken)
{
// 恭喜您，註冊成功，歡迎加入我們。

return Task.CompletedTask;
}

// 學生被修改成功後的事件處理方法
public Task Handle(StudentUpdatedEvent message, CancellationToken cancellationToken)
{
// 恭喜您，更新成功，請牢記修改後的資訊。

return Task.CompletedTask;
}

// 學習被刪除後的事件處理方法
public Task Handle(StudentRemovedEvent message, CancellationToken cancellationToken)
{
// 您已經刪除成功啦，記得以後常來看看。

return Task.CompletedTask;
}
}
}

相信大家應該都能看的明白，在上邊的註釋已經很清晰的表達了響應的作用，如果有看不懂，咱們可以一起交流。

好啦，現在第二步已經完成，剩下最後一步：如何通過事件匯流排分發我們的事件模型了。

3、在事件匯流排EventBus中引發事件

這個使用起來很簡單，主要是我們在命令處理程式中，處理完了持久化以後，接下來呼叫我們的事件匯流排，對不同的事件模型進行分發，就比如我們的 新增Student 命令處理程式方法中，我們通過工作單元新增成功後，需要做下一步，比如發郵件，那我們就需要這麼做。

在命令處理程式 StudentCommandHandler.cs 中，完善我們的提交成功的處理：

 // 持久化
 _studentRepository.Add(customer);

 // 統一提交
 if (Commit())
 {
// 提交成功後，這裡需要釋出領域事件
// 比如歡迎使用者註冊郵件呀，簡訊呀等
Bus.RaiseEvent(new StudentRegisteredEvent(customer.Id, customer.Name, customer.Email, customer.BirthDate,customer.Phone));
 }

這樣就很簡單的將我們的事件模型分發到了事件匯流排中去了，這個時候記得要在 IoC 專案中，進行注入。關於觸發過程下邊我簡單說一下。

4、整體事件驅動執行過程

說到了這裡，你可能發現和命令匯流排很相似，也可能不是很懂，簡單來說，整體流程是這樣的：

1、首先我們在命令處理程式中呼叫事件匯流排來引發事件  Bus.RaiseEvent(........)；
2、然後在Bus中，將我們的事件模型進行包裝成固定的格式   _mediator.Publish(@event)；
3、然後通過注入的方法，將包裝後的事件模型與事件處理程式進行匹配，系統執行事件模型，就自動例項化事件處理程式 StudentEventHandler；
4、最後執行我們Handler 中各自的處理方法 Task Handle(StudentRegisteredEvent message)。

希望正好也溫習下命令匯流排的執行過程。

5、依賴注入事件模型和處理程式

 // Domain - Events
 // 將事件模型和事件處理程式匹配注入
 services.AddScoped<INotificationHandler<StudentRegisteredEvent>, StudentEventHandler>();
 services.AddScoped<INotificationHandler<StudentUpdatedEvent>, StudentEventHandler>();
 services.AddScoped<INotificationHandler<StudentRemovedEvent>, StudentEventHandler>();

這個時候，我們DDD領域驅動設計核心篇的第一部分就是這樣了，還剩下最後的，事件驅動的 事件源 和 事件儲存/回溯 ，我們下一講再說。

接下來咱們說說領域通知，為什麼要說領域通知呢，大家應該還記得我們之前將錯誤資訊放到了記憶體中，無論是操作還是業務上都很嚴重的問題，肯定是不可取的。那我們應該採用什麼辦法呢，欸？！沒錯，你會發現，通過上邊的事件驅動設計，發現領域通知我們也可以採用這個方法，首先是多個模型之間相互通訊，但又不相互引用；而且也在命令處理程式中，對資訊進行分發，和發郵件很類似，那具體如何操作呢，請往下看。

四、事件分發的另一個用途 —— 領域通知

1、領域通知模型 DomainNotification

這個通知模型，就像是一個訊息佇列一樣，在我們的記憶體中，通過通知處理程式進行釋出和使用，有自己的生命週期，當被訪問並呼叫完成的時候，會手動對其進行回收，以保證資料的完整性和一致性，這個就很好的解決了咱們之前用Memory快取通知資訊的弊端。

在我們的核心領域層 Christ3D.Domain.Core 中，新建資料夾 Notifications ，然後新增領域通知模型 DomainNotification.cs：

namespace Christ3D.Domain.Core.Notifications
{
/// <summary>
/// 領域通知模型，用來獲取當前匯流排中出現的通知資訊
/// 繼承自領域事件和 INotification（也就意味著可以擁有中介的釋出/訂閱模式）
/// </summary>
public class DomainNotification : Event
{
// 標識
public Guid DomainNotificationId { get; private set; }
// 鍵（可以根據這個key，獲取當前key下的全部通知資訊）
// 這個我們在事件源和事件回溯的時候會用到，伏筆
public string Key { get; private set; }
// 值（與key對應）
public string Value { get; private set; }
// 版本資訊
public int Version { get; private set; }

public DomainNotification(string key, string value)
{
DomainNotificationId = Guid.NewGuid();
Version = 1;
Key = key;
Value = value;
}
}
}

2、領域通知處理程式 DomainNotificationHandler

該處理程式，可以理解成，就像一個類的管理工具，在每次物件生命週期內 ，對領域通知進行例項化，獲取值，手動回收，這樣保證了每次訪問的都是當前例項的資料。

還是在資料夾 Notifications 下，新建處理程式 DomainNotificationHandler.cs：

namespace Christ3D.Domain.Core.Notifications
{
/// <summary>
/// 領域通知處理程式，把所有的通知資訊放到事件匯流排中
/// 繼承 INotificationHandler<T>
/// </summary>
public class DomainNotificationHandler : INotificationHandler<DomainNotification>
{
// 通知資訊列表
private List<DomainNotification> _notifications;

// 每次訪問該處理程式的時候，例項化一個空集合
public DomainNotificationHandler()
{
_notifications = new List<DomainNotification>();
}

// 處理方法，把全部的通知資訊，新增到記憶體裡
public Task Handle(DomainNotification message, CancellationToken cancellationToken)
{
_notifications.Add(message);
return Task.CompletedTask;
}

// 獲取當前生命週期內的全部通知資訊
public virtual List<DomainNotification> GetNotifications()
{
return _notifications;
}

// 判斷在當前匯流排物件週期中，是否存在通知資訊
public virtual bool HasNotifications()
{
return GetNotifications().Any();
}

// 手動回收（清空通知）
public void Dispose()
{
_notifications = new List<DomainNotification>();
}
}
}

到了目前為止，我們的DDD領域驅動設計中的 核心領域層 部分，已經基本完成了（還剩下下一篇的事件源、事件回溯）：

3、在命令處理程式中釋出通知

我們定義好了領域通知的處理程式，我們就可以像上邊的釋出事件一樣，來發布我們的通知資訊了。這裡用一個栗子來試試：

在學習命令處理程式 StudentCommandHandler.cs 中的 RegisterStudentCommand 處理方法中，完善：

 // 判斷郵箱是否存在
 // 這些業務邏輯，當然要在領域層中（領域命令處理程式中）進行處理
 if (_studentRepository.GetByEmail(customer.Email) != null)
 {
////這裡對錯誤資訊進行釋出，目前採用快取形式
//List<string> errorInfo = new List<string>() { "該郵箱已經被使用！" };
//Cache.Set("ErrorData", errorInfo);

//引發錯誤事件
Bus.RaiseEvent(new DomainNotification("", "該郵箱已經被使用！"));
return Task.FromResult(new Unit());
 }

這個時候，我們把錯誤通知資訊在事件匯流排中釋出出去，剩下的就是需要在別的任何地方訂閱即可，還記得哪裡麼，沒錯就是我們的自定義檢視元件中，我們需要訂閱通知資訊，展示在頁面裡。

4、在檢視元件中獲取通知資訊

這個很簡單，之前我們用的是注入 IMemory 的方式，在快取中獲取，現在我們通過注入領域通知處理程式來實現，在檢視元件 AlertsViewComponent.cs 中：

public class AlertsViewComponent : ViewComponent
{
// 快取注入，為了收錄資訊（錯誤方法，以後會用通知，通過領域事件來替換）
// private IMemoryCache _cache;
// 領域通知處理程式
private readonly DomainNotificationHandler _notifications;

// 建構函式注入
public AlertsViewComponent(INotificationHandler<DomainNotification> notifications)
{
_notifications = (DomainNotificationHandler)notifications;
}

/// <summary>
/// Alerts 檢視元件
/// 可以非同步，也可以同步，注意方法名稱，同步的時候是Invoke
/// 我寫非同步是為了為以後做準備
/// </summary>
/// <returns></returns>
public async Task<IViewComponentResult> InvokeAsync()
{
// 從通知處理程式中，獲取全部通知資訊，並返回給前臺
var notificacoes = await Task.FromResult((_notifications.GetNotifications()));
notificacoes.ForEach(c => ViewData.ModelState.AddModelError(string.Empty, c.Value));

return View();
}
}

5、StudentController 判斷是否有通知資訊

通過注入的方式，把 INotificationHandler<DomainNotification> 注入控制器，然後因為這個介面可以例項化多個物件，那我們就強型別轉換成 DomainNotificationHandler：

這裡要說明下，記得要對事件處理程式注入，才能使用：

 // 將事件模型和事件處理程式匹配注入
 services.AddScoped<INotificationHandler<DomainNotification>, DomainNotificationHandler>();

五、結語

好啦，今天的講解基本就到這裡了，今天重點說明了，我們如何使用事件匯流排，已經事件驅動模型下如何定義事件模型和事件處理程式，如果你都看懂了呢，這裡可以簡單回想一下以下幾個問題：

1、為什麼要定義事件驅動呢？（提示詞：業務分離）

2、我們是在哪裡釋出這些事件的呢？（提示詞：.publish()方法）

3、事件驅動中的生命週期是從哪裡開始到哪裡接受的？（提示：處理程式Handler）

如果你對以上的內容還是比較困惑呢，這裡有兩個文章可以參考，當然，多溝通才是關鍵！

https://www.cnblogs.com/lori/p/4080426.html

https://blog.csdn.net/sD7O95O/article/details/79609305

六、GitHub & Gitee

https://github.com/anjoy8/ChristDDD

https://gitee.com/laozhangIsPhi/ChristDDD

--END