通過事件進行應用程序的設計是自20世紀80年代后期以來的一種實踐。我們可以在前端或后端的任何地方使用事件。當按下按鈕時，某些數據發生更改或執行某個后端動作。

但是事件究竟是什么呢？我們什么時候應該用它呢？缺點是什么？

What/When/Why

當類或組件之間內聚性很高，它們的耦合度應該很低，也就是說當組件需要相互協作調用時，比如我們假設一個組件“A”需要觸發組件“B”中的一些邏輯，自然的方式是直接讓組件A調用組件B中的一個方法。但前提是A必須知道B的存在，這樣它們之間就是耦合的，A必須依賴于B了，這會使得系統更難以改變和維護。因此，這里可以使用事件來防止這種直接調用的耦合。

此外，使用事件實現組件解耦也有其另外的，如果我們有一個只負責組件B的工作團隊，那么他們則可能不需要與負責組件A的團隊進行交流，直接針對組件A中的邏輯改變在組件B中做出相對反應。兩個組件團隊可以獨立發展（banq注：微服務特點之一）， 我們的應用系統變得更靈活。

即使在同一個組件團隊中，有時候我們不需要在同一請求/響應中立即執行一個動作的結果，只要異步執行這個動作，比如發送電子郵件。在這種情況下，我們可以立即向用戶返回響應，并以異步方式發送電子郵件，并避免讓用戶等待發送電子郵件。

不過，如果我們不加區別地使用它，也有危險。我們會遇到邏輯流程的風險，這些邏輯流程在概念上是高度凝聚力的，但是通過采取脫鉤機制的事件連接在一起。換句話說，應該在一起的代碼將被分開，并且難以跟蹤它的流程（類似于goto語句），不易于理解：可能是意大利面一樣混在一起！

?

為了防止將我們的代碼庫變成一大堆意大利面條，我們應該將事件的使用限制在明確的情況下。根據我的經驗，有三種使用事件的情況：

（1）去耦組件

（2）執行異步任務

（3）跟蹤狀態變化（審核日志）

1.去耦組件（微服務）

當組件A執行的邏輯需要觸發組件B的邏輯時，不要直接調用它，我們可以將觸發事件發送到事件分派器。組件B將偵聽調度程序中的特定事件，并在事件發生時執行操作。

這意味著A和B都將取決于調度器和事件，但他們之間將不會知道對方存在，它們將被解耦。

理想情況下，調度員和事件都不應該在兩個組件之間存在：

（1）調度員應該是完全獨立于我們應用程序的庫，因此使用依賴管理系統安裝在通用位置。在PHP世界中，這是使用Composer等安裝在vendor文件夾中的東西。

（2） 事件是我們的應用程序的一部分，應該在兩個組件之間生存，組件之間通過事件進行通訊（結構上解耦，行為上耦合）。事件在組件之間共享，它是應用程序的核心部分。事件在DDD中屬于共享內核Shared Kernel的一部分。這樣，兩個組件都將依賴于共享內核，但彼此不會意識到。然而在單體Monolithic應用程序中，為方便起見，可以將其放在觸發事件的組件中。

DDD共享內核

［。..］明確界定指定團隊同意分享的領域模型的一些子集。保持這個內核很小。［。..］這個明確共享的東西有特殊的地位，如果沒有與其他團隊協商，不應該改變。

Eric Evans 2014， 領域驅動設計參考

2.執行異步任務

有時候我們有一個我們想要執行的邏輯，但它可能需要相當長的時間來執行，我們不想讓用戶等待它完成。在這種情況下，希望將其作為異步工作運行，并立即返回給用戶的消息，通知他請求將在以后異步執行。

例如，在網上商店下訂單可以同步完成，但發送通知用戶的電子郵件可以進行異步。

在這種情況下，我們可以做的是觸發一個將被排隊的事件，直到一個工作任務可以獲得這個事件并執行它，只要系統有資源。

在這些情況下，相關聯的邏輯是否在相同的有界環境中并不重要，無論哪種方式，邏輯都是去耦的。

3.跟蹤狀態變化（審計日志）

以傳統的數據存儲方式，我們擁有一些數據的實體。當這些實體中的數據發生變化時，我們只需更新數據庫表行以反映新值。

這里的問題是，我們并不存儲這些值為什么改變且什么時候改變。

我們可以將這些改變的事件存儲在審計日志中。

更多關于這個進一步的前景，在關于事件溯源的解釋。

事件模式

Martin Fowler確定了三種不同類型的事件模式：

（1）事件通知

（2）事件執行狀態轉移

（3）事件溯源Event Sourcing

所有這些模式共享相同的關鍵概念：

（1）事件是代表發生了一些事情（發生在某事之后）;

（2）事件被廣播到正在監聽的任何代碼（代碼可以對事件做出反應）。

一。 事件通知

假設我們有一個具有明確定義的組件作為應用程序核心。理想情況下，這些組件是完全相互分離的，但是它們的一些功能需要在其他組件中執行一些邏輯。

最典型的情況如前所述：當組件A執行的邏輯需要觸發組件B的邏輯時，A不是直接去調用B，而是觸發事件將且發送到事件調度程序。組件B將偵聽調度程序中的特定事件，并在事件發生時執行操作。

重要的是，這種模式的一個特征是事件攜帶最少的數據。它只為聽眾提供足夠的數據，以便知道發生了什么并執行其代碼，通常只是實體ID，也可能是事件創建的日期和時間。

優點

（1）彈性更大：將事件排隊后，發送方組件可以繼續執行其自己邏輯，即使由于錯誤發生，因為它們排隊等候，它們可以在錯誤被修復時被執行。

（2）降低延遲，如果事件排隊，用戶不需要等待該邏輯執行;

團隊可以獨立發展組件，使他們的工作更輕松，更快，更容易出現問題，更靈活;

缺點

（1）如果沒有使用標準，有可能變成一堆意大利面條代碼。

二。 事件執行狀態轉移

讓我們再次看看前面例子，一個具有明確定義的組件作為應用程序核心。如果A組件一些功能需要來自其他組件的數據。獲得該數據的最自然的方法是詢問其他組件，但這意味著被查詢組件必須提供查詢方法以供查詢組件使用，一次兩次修改增加無所謂，如果頻繁要求被查詢組件提供新的查詢方法，說明這兩個組件彼此耦合！

在組件之間共享數據的另一種方法是：擁有數據的組件觸發的更改事件時，該事件將攜帶全新更改后的數據。對該數據感興趣的組件將會監聽這些事件，從事件中獲得數據并存儲該數據的本地副本，然后進一步對這些全新數據做出反應。這樣，當他們需要外部數據時，他們其實在本地已經擁有它們，它們將不需要查詢其他組件，也不需要其他組件提供對應的查詢方法。

優點

（1）更大的彈性，查詢組件不依賴被查詢組件，如果被查詢組件變得不可用（因為有一個錯誤或遠程服務器是不可達到的），查詢組件自身能正常工作，因為擁有了被查詢組件中主數據的本地數據;

（2）減少延遲，因為沒有遠程呼叫（假設被查詢組件是遠程的）訪問數據;

（3）我們不必擔心被查詢組件上的負載了，不用擔心它是否滿足來自所有其他查詢組件的查詢（特別是如果它是遠程組件）;

缺點

（1）將有幾個相同數據的副本，雖然它們是只讀副本，數據存儲在當下已經不是問題;

（2）更高的查詢組件的復雜性，因為它將需要邏輯來維護外部數據的本地副本，盡管這是非常標準的邏輯。主從一致性。

如果兩個組件在同一個進程中（同一個VM中、同一個主機內）執行，這種模式也許沒有必要，但即使這樣，它也可能很有趣，可以將其用于解耦和可維護性，或作為將這些組件分離到不同的微服務中工作做準備，也許在未來的某個時候我們能平滑升級到微服務。這一切都取決于我們目前的需求，未來的需求。

三。 事件溯源

我們假設一個實體處于一種初始狀態。作為一個實體，它有自己的身份，代表在現實世界中一個特定的事情，應用程序將其建模為實體。在其生命周期中，實體數據會發生變化，并且傳統上實體的當前狀態被簡單地作為表的一行記錄存儲在數據庫中。

（1）事務日志

這在大多數情況下都是可以的，但如果我們需要知道實體是如何達到當前這個狀態，即我們想知道我們的銀行賬戶的貸方和借記發生的每筆金額，才能知道當前賬戶的余額來歷，這在傳統只保存當前狀態的方式下是不可能實現的，因為我們只存儲當前狀態！每次都是新的余額狀態覆蓋了之前的狀態，比如當前余額是10，覆蓋了之前余額90，至于賬戶余額怎么剩余10元呢？如果數據庫不保存往來明細，你可能認為銀行系統出問題了。

存儲實體發生的事件，而不是存儲Entity狀態，我們專注于存儲實體狀態更改并從這些更改中計算實體狀態。每個狀態變化是一個事件，存儲在事件流中（即RDBMS中的一個表）。當我們需要實體的當前狀態時，我們從事件流中的所有事件中計算出它。

事件存儲成為真相的主要來源，系統狀態純粹源于它。對于程序員來說，最好的例子是版本控制系統。所有提交的日志是事件存儲，源樹的工作副本是系統狀態。---2010年Greg Young， CQRS文件

（2）如何刪除？

如果我們發現一個狀態改變（事件）是一個錯誤，我們不能簡單地刪除該事件，因為這會改變狀態更改歷史記錄，這將違反整個事情溯源的想法。相反，我們在事件流中創建一個事件，以反轉我們要刪除的事件。這個過程稱為反轉事務，不僅使實體返回到所需的狀態，而且留下了一個跟蹤，顯示對象在給定時間點處于該狀態。

不刪除數據也具有架構優勢。存儲系統成為只添加一個體系結構，眾所周知，僅附加體系結構比更新架構更容易分發，因為要處理的鎖少得多。---2010年Greg Young， CQRS文件

（3）快照

但是，當事件流中有許多事件時，計算實體狀態將是非常昂貴的，因此為了避免出現這種情況。每X個事件我們將在該時刻創建一個實體狀態的快照。這樣，當我們需要實體狀態時，我們只需要計算它到最后一個快照。我們甚至可以永久保存更新實體的快照，這樣我們平衡了兩種世界（只保存狀態和只保存事件）。

（4）投影預測Projections

在事件采集中，我們也有一個投影的概念，即事件流中的事件的計算，從特定時刻開始。這意味著快照或實體的當前狀態符合預測的定義。但是在預測概念中最有價值的想法是，我們可以在特定時期分析實體的“行為”，這使我們能夠對未來作出有根據的猜測（即如果在過去的5年中，實體有8月份的活動增加，明年8月份可能會發生同樣的事情），這對業務來說可能是非常有價值的。

（5）利弊

事件溯源對于業務和開發過程都是非常有用的：

1.我們查詢這些事件，用于業務和開發，以了解用戶和系統行為（調試）;

2.我們還可以使用事件日志重建過去的狀態，對于業務和開發來說都是有用的;

3.自動調整狀態以應對追溯變化，非常適合企業需要頻繁變化;

4.通過在重播時注入假想事件來探索其他歷史，令人敬畏。

但不是一切都是好消息，要注意隱藏的問題：

1.外部更新

當我們的事件在外部系統中觸發更新時，但是我們又在重播事件以便創建投影，因此我們不想重新觸發這些事件。在這一點上，當我們處于“重播模式”時，我們可以簡單地禁用外部更新，也可以將該邏輯封裝在網關中。

另一個解決方案取決于實際問題，可能是將外部系統更新放入緩沖，在一段時間后執行，保證事件不會被重播時再進行。

2.外部查詢

當我們的事件使用對外部系統的查詢，如獲得股票評級，當我們重播事件以創建投影時會發生什么？我們可能希望獲得與事件在第一次運行時所使用的相同的等級，也許是在幾年前。因此，遠程應用程序可以給我們這些值，或者我們需要將它們存儲在系統中，所以我們可以通過在網關中封裝該邏輯來模擬遠程查詢。

3.代碼更改

Martin Fowler發現3種類型的代碼更改：新功能，錯誤修復和時間邏輯。當在不同的時間點播放應該使用不同業務邏輯規則的事件時，真正的問題就出現。去年的稅收計算與今年不同。像往常一樣，條件邏輯可以使用，但它會變得凌亂，所以建議使用策略模式。

所以，我建議謹慎對待，盡可能遵循這些規則：

1.保持事態愚蠢，只關心狀態的變化，而不是如何被改變的。這樣我們可以安全地重播任何事件，并期望結果是一樣的，即使業務規則同時發生變化（盡管我們需要保留舊的業務規則，以便我們可以在重播過去的事件時應用它們）;

2.與外部系統的交互不應該依賴于這些事件，這樣我們可以安全地重播事件，而不會重新觸發外部邏輯，我們不需要確保來自外部系統的回復與最初的事件相同。

當然，像其他任何模式一樣，我們不需要在任何地方使用它，我們應該使用它在哪里是有意義的，它給我們帶來了一個優勢，并解決了比創建更多的問題。

結論

這又是關于封裝，低耦合和高凝聚的問題。

事件可以平衡代碼的可維護性、性能和擴展性，事件溯源也是系統數據可提供的可靠性和信息。

然而，這是一條存在自身危險的道路，因為概念和技術的復雜性都會增加，而且任何一種的濫用都會產生災難性的后果。
來源：tuicool