通過事件進(jìn)行應(yīng)用程序的設(shè)計(jì)是自20世紀(jì)80年代后期以來的一種實(shí)踐。我們可以在前端或后端的任何地方使用事件。當(dāng)按下按鈕時，某些數(shù)據(jù)發(fā)生更改或執(zhí)行某個后端動作。

但是事件究竟是什么呢？我們什么時候應(yīng)該用它呢？缺點(diǎn)是什么？

What/When/Why

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

此外，使用事件實(shí)現(xiàn)組件解耦也有其另外的，如果我們有一個只負(fù)責(zé)組件B的工作團(tuán)隊(duì)，那么他們則可能不需要與負(fù)責(zé)組件A的團(tuán)隊(duì)進(jìn)行交流，直接針對組件A中的邏輯改變在組件B中做出相對反應(yīng)。兩個組件團(tuán)隊(duì)可以獨(dú)立發(fā)展（banq注：微服務(wù)特點(diǎn)之一）， 我們的應(yīng)用系統(tǒng)變得更靈活。

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

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

?

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

（1）去耦組件

（2）執(zhí)行異步任務(wù)

（3）跟蹤狀態(tài)變化（審核日志）

1.去耦組件（微服務(wù)）

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

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

理想情況下，調(diào)度員和事件都不應(yīng)該在兩個組件之間存在：

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

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

DDD共享內(nèi)核

［。..］明確界定指定團(tuán)隊(duì)同意分享的領(lǐng)域模型的一些子集。保持這個內(nèi)核很小。［。..］這個明確共享的東西有特殊的地位，如果沒有與其他團(tuán)隊(duì)協(xié)商，不應(yīng)該改變。

Eric Evans 2014， 領(lǐng)域驅(qū)動設(shè)計(jì)參考

2.執(zhí)行異步任務(wù)

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

例如，在網(wǎng)上商店下訂單可以同步完成，但發(fā)送通知用戶的電子郵件可以進(jìn)行異步。

在這種情況下，我們可以做的是觸發(fā)一個將被排隊(duì)的事件，直到一個工作任務(wù)可以獲得這個事件并執(zhí)行它，只要系統(tǒng)有資源。

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

3.跟蹤狀態(tài)變化（審計(jì)日志）

以傳統(tǒng)的數(shù)據(jù)存儲方式，我們擁有一些數(shù)據(jù)的實(shí)體。當(dāng)這些實(shí)體中的數(shù)據(jù)發(fā)生變化時，我們只需更新數(shù)據(jù)庫表行以反映新值。

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

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

更多關(guān)于這個進(jìn)一步的前景，在關(guān)于事件溯源的解釋。

事件模式

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

（1）事件通知

（2）事件執(zhí)行狀態(tài)轉(zhuǎn)移

（3）事件溯源Event Sourcing

所有這些模式共享相同的關(guān)鍵概念：

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

（2）事件被廣播到正在監(jiān)聽的任何代碼（代碼可以對事件做出反應(yīng)）。

一。 事件通知

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

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

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

優(yōu)點(diǎn)

（1）彈性更大：將事件排隊(duì)后，發(fā)送方組件可以繼續(xù)執(zhí)行其自己邏輯，即使由于錯誤發(fā)生，因?yàn)樗鼈兣抨?duì)等候，它們可以在錯誤被修復(fù)時被執(zhí)行。

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

團(tuán)隊(duì)可以獨(dú)立發(fā)展組件，使他們的工作更輕松，更快，更容易出現(xiàn)問題，更靈活;

缺點(diǎn)

（1）如果沒有使用標(biāo)準(zhǔn)，有可能變成一堆意大利面條代碼。

二。 事件執(zhí)行狀態(tài)轉(zhuǎn)移

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

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

優(yōu)點(diǎn)

（1）更大的彈性，查詢組件不依賴被查詢組件，如果被查詢組件變得不可用（因?yàn)橛幸粋€錯誤或遠(yuǎn)程服務(wù)器是不可達(dá)到的），查詢組件自身能正常工作，因?yàn)閾碛辛吮徊樵兘M件中主數(shù)據(jù)的本地?cái)?shù)據(jù);

（2）減少延遲，因?yàn)闆]有遠(yuǎn)程呼叫（假設(shè)被查詢組件是遠(yuǎn)程的）訪問數(shù)據(jù);

（3）我們不必?fù)?dān)心被查詢組件上的負(fù)載了，不用擔(dān)心它是否滿足來自所有其他查詢組件的查詢（特別是如果它是遠(yuǎn)程組件）;

缺點(diǎn)

（1）將有幾個相同數(shù)據(jù)的副本，雖然它們是只讀副本，數(shù)據(jù)存儲在當(dāng)下已經(jīng)不是問題;

（2）更高的查詢組件的復(fù)雜性，因?yàn)樗鼘⑿枰壿媮砭S護(hù)外部數(shù)據(jù)的本地副本，盡管這是非常標(biāo)準(zhǔn)的邏輯。主從一致性。

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

三。 事件溯源

我們假設(shè)一個實(shí)體處于一種初始狀態(tài)。作為一個實(shí)體，它有自己的身份，代表在現(xiàn)實(shí)世界中一個特定的事情，應(yīng)用程序?qū)⑵浣閷?shí)體。在其生命周期中，實(shí)體數(shù)據(jù)會發(fā)生變化，并且傳統(tǒng)上實(shí)體的當(dāng)前狀態(tài)被簡單地作為表的一行記錄存儲在數(shù)據(jù)庫中。

（1）事務(wù)日志

這在大多數(shù)情況下都是可以的，但如果我們需要知道實(shí)體是如何達(dá)到當(dāng)前這個狀態(tài)，即我們想知道我們的銀行賬戶的貸方和借記發(fā)生的每筆金額，才能知道當(dāng)前賬戶的余額來歷，這在傳統(tǒng)只保存當(dāng)前狀態(tài)的方式下是不可能實(shí)現(xiàn)的，因?yàn)槲覀冎淮鎯Ξ?dāng)前狀態(tài)！每次都是新的余額狀態(tài)覆蓋了之前的狀態(tài)，比如當(dāng)前余額是10，覆蓋了之前余額90，至于賬戶余額怎么剩余10元呢？如果數(shù)據(jù)庫不保存往來明細(xì)，你可能認(rèn)為銀行系統(tǒng)出問題了。

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

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

（2）如何刪除？

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

不刪除數(shù)據(jù)也具有架構(gòu)優(yōu)勢。存儲系統(tǒng)成為只添加一個體系結(jié)構(gòu)，眾所周知，僅附加體系結(jié)構(gòu)比更新架構(gòu)更容易分發(fā)，因?yàn)橐幚淼逆i少得多。---2010年Greg Young， CQRS文件

（3）快照

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

（4）投影預(yù)測Projections

在事件采集中，我們也有一個投影的概念，即事件流中的事件的計(jì)算，從特定時刻開始。這意味著快照或?qū)嶓w的當(dāng)前狀態(tài)符合預(yù)測的定義。但是在預(yù)測概念中最有價值的想法是，我們可以在特定時期分析實(shí)體的“行為”，這使我們能夠?qū)ξ磥碜鞒鲇懈鶕?jù)的猜測（即如果在過去的5年中，實(shí)體有8月份的活動增加，明年8月份可能會發(fā)生同樣的事情），這對業(yè)務(wù)來說可能是非常有價值的。

（5）利弊

事件溯源對于業(yè)務(wù)和開發(fā)過程都是非常有用的：

1.我們查詢這些事件，用于業(yè)務(wù)和開發(fā)，以了解用戶和系統(tǒng)行為（調(diào)試）;

2.我們還可以使用事件日志重建過去的狀態(tài)，對于業(yè)務(wù)和開發(fā)來說都是有用的;

3.自動調(diào)整狀態(tài)以應(yīng)對追溯變化，非常適合企業(yè)需要頻繁變化;

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

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

1.外部更新

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

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

2.外部查詢

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

3.代碼更改

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

所以，我建議謹(jǐn)慎對待，盡可能遵循這些規(guī)則：

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

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

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

結(jié)論

這又是關(guān)于封裝，低耦合和高凝聚的問題。

事件可以平衡代碼的可維護(hù)性、性能和擴(kuò)展性，事件溯源也是系統(tǒng)數(shù)據(jù)可提供的可靠性和信息。

然而，這是一條存在自身危險的道路，因?yàn)楦拍詈图夹g(shù)的復(fù)雜性都會增加，而且任何一種的濫用都會產(chǎn)生災(zāi)難性的后果。
來源：tuicool