---

Pre

DDD - 微服務(wù)設(shè)計與領(lǐng)域驅(qū)動設(shè)計實戰(zhàn)(中)_ 解決微服務(wù)拆分難題

EDA - Spring Boot構(gòu)建基于事件驅(qū)動的消息系統(tǒng)

---

領(lǐng)域事件的核心概念

領(lǐng)域事件（Domain Event）是領(lǐng)域驅(qū)動設(shè)計（DDD）中的一個重要概念，用于表示在領(lǐng)域中發(fā)生的、對業(yè)務(wù)有重要意義的事件。這些事件通常會導(dǎo)致進一步的業(yè)務(wù)操作，并且在微服務(wù)架構(gòu)中，領(lǐng)域事件是實現(xiàn)微服務(wù)解耦的關(guān)鍵機制之一。

領(lǐng)域事件的作用

1. 業(yè)務(wù)解耦：領(lǐng)域事件可以切斷微服務(wù)之間的強依賴關(guān)系，發(fā)布方只需發(fā)布事件，而不需要關(guān)心訂閱方的處理結(jié)果，從而實現(xiàn)微服務(wù)之間的解耦。

2. 業(yè)務(wù)閉環(huán)：領(lǐng)域事件有助于形成完整的業(yè)務(wù)閉環(huán)。通過事件驅(qū)動的方式，業(yè)務(wù)流程可以在不同的微服務(wù)之間流轉(zhuǎn)，確保業(yè)務(wù)的連續(xù)性和一致性。

3. 最終一致性：在微服務(wù)架構(gòu)中，領(lǐng)域事件通常采用最終一致性，而不是強一致性。這種方式可以減少分布式事務(wù)的使用，提升系統(tǒng)的性能和可擴展性。

---

領(lǐng)域事件的識別

在業(yè)務(wù)分析過程中，可以通過以下關(guān)鍵詞來識別領(lǐng)域事件：

• “如果發(fā)生……，則……”
• “當做完……的時候，請通知……”
• “發(fā)生……時，則……”

這些場景中的事件通常會導(dǎo)致進一步的業(yè)務(wù)操作，因此可以被識別為領(lǐng)域事件。

介紹一個保險承保業(yè)務(wù)過程中有關(guān)領(lǐng)域事件的案例。一個保單的生成，經(jīng)歷了很多子域、業(yè)務(wù)狀態(tài)變更和跨微服務(wù)業(yè)務(wù)數(shù)據(jù)的傳遞。這個過程會產(chǎn)生很多的領(lǐng)域事件，這些領(lǐng)域事件促成了保險業(yè)務(wù)數(shù)據(jù)、對象在不同的微服務(wù)和子域之間的流轉(zhuǎn)和角色轉(zhuǎn)換。
在下面這張圖中，列出了幾個關(guān)鍵流程，用來說明如何用領(lǐng)域事件驅(qū)動設(shè)計來驅(qū)動承保業(yè)務(wù)流程

事件起點：客戶購買保險 - 業(yè)務(wù)人員完成保單錄入 - 生成投保單 - 啟動繳費動作

1. 投保微服務(wù)生成繳費通知單，發(fā)布第一個事件：繳費通知單已生成，將繳費通知單數(shù)據(jù)發(fā)布到消息中間件。收款微服務(wù)訂閱繳費通知單事件，完成繳費操作。繳費通知單已生成，領(lǐng)域事件結(jié)束。
2. 收款微服務(wù)繳費完成后，發(fā)布第二個領(lǐng)域事件：繳費已完成，將繳費數(shù)據(jù)發(fā)布到消息中間件。原來的訂閱方收款微服務(wù)這時則變成了發(fā)布方。原來的事件發(fā)布方投保微服務(wù)轉(zhuǎn)換為訂閱方。投保微服務(wù)在收到繳費信息并確認繳費完成后，完成投保單轉(zhuǎn)成保單的操作。繳費已完成，領(lǐng)域事件結(jié)束。
3. 投保微服務(wù)在投保單轉(zhuǎn)保單完成后，發(fā)布第三個領(lǐng)域事件：保單已生成，將保單數(shù)據(jù)發(fā)布到消息中間件。保單微服務(wù)接收到保單數(shù)據(jù)后，完成保單數(shù)據(jù)保存操作。保單已生成，領(lǐng)域事件結(jié)束。
4. 保單微服務(wù)完成保單數(shù)據(jù)保存后，后面還會發(fā)生一系列的領(lǐng)域事件，以并發(fā)的方式將保單數(shù)據(jù)通過消息中間件發(fā)送到傭金、收付費和再保等微服務(wù)，一直到財務(wù)，完后保單后續(xù)所有業(yè)務(wù)流程。這里就不詳細說了。

總之，通過領(lǐng)域事件驅(qū)動的異步化機制，可以推動業(yè)務(wù)流程和數(shù)據(jù)在各個不同微服務(wù)之間的流轉(zhuǎn)，實現(xiàn)微服務(wù)的解耦，減輕微服務(wù)之間服務(wù)調(diào)用的壓力，提升用戶體驗。

---

領(lǐng)域事件的技術(shù)實現(xiàn)

領(lǐng)域事件的執(zhí)行需要一系列的組件和技術(shù)來支撐。我們來看一下這個領(lǐng)域事件總體技術(shù)架構(gòu)圖，領(lǐng)域事件處理包括：事件構(gòu)建和發(fā)布、事件數(shù)據(jù)持久化、事件總線、消息中間件、事件接收和處理等

領(lǐng)域事件的技術(shù)實現(xiàn)通常包括以下幾個步驟：

1. 事件構(gòu)建和發(fā)布：

   • 事件的基本屬性包括事件唯一標識、發(fā)生時間、事件類型和事件源。
   • 事件的業(yè)務(wù)屬性記錄事件發(fā)生時的業(yè)務(wù)數(shù)據(jù)，這些數(shù)據(jù)會隨事件傳輸?shù)接嗛喎健?/li>
   • 事件發(fā)布可以通過應(yīng)用服務(wù)、領(lǐng)域服務(wù)或消息中間件來完成。

2. 事件數(shù)據(jù)持久化：

   • 事件數(shù)據(jù)持久化可以用于系統(tǒng)之間的數(shù)據(jù)對賬或?qū)徲嫛?/li>
   • 事件數(shù)據(jù)可以持久化到本地業(yè)務(wù)數(shù)據(jù)庫的事件表中，或者持久化到共享的事件數(shù)據(jù)庫中。

3. 事件總線（EventBus）：

   • 事件總線是微服務(wù)內(nèi)聚合之間領(lǐng)域事件的重要組件，負責(zé)事件的分發(fā)和接收。
   • 事件總線可以同步或異步地傳遞數(shù)據(jù)，確保事件在微服務(wù)內(nèi)外的訂閱者之間正確傳遞。

4. 消息中間件：

   • 跨微服務(wù)的領(lǐng)域事件通常使用消息中間件（如Kafka、RabbitMQ）來實現(xiàn)事件的發(fā)布和訂閱。
   • 消息中間件可以確保事件在微服務(wù)之間的可靠傳遞。

5. 事件接收和處理：

   • 訂閱方通過監(jiān)聽機制接收事件數(shù)據(jù)，并將其持久化到本地數(shù)據(jù)庫。
   • 訂閱方在領(lǐng)域服務(wù)中處理事件，完成后續(xù)的業(yè)務(wù)操作。

---

領(lǐng)域事件的運行機制案例

以保險承保業(yè)務(wù)為例，領(lǐng)域事件的運行機制如下：

事件起點：出單員生成投保單，核保通過后，發(fā)起生成繳費通知單的操作。

1. 繳費通知單生成：

   • 投保微服務(wù)生成繳費通知單，并發(fā)布“繳費通知單已生成”事件。
   • 收款微服務(wù)訂閱該事件，完成繳費操作。

2. 繳費完成：

   • 收款微服務(wù)繳費完成后，發(fā)布“繳費已完成”事件。
   • 投保微服務(wù)訂閱該事件，完成投保單轉(zhuǎn)保單的操作。

3. 保單生成：

   • 投保微服務(wù)在投保單轉(zhuǎn)保單完成后，發(fā)布“保單已生成”事件。
   • 保單微服務(wù)訂閱該事件，完成保單數(shù)據(jù)的保存操作。

4. 后續(xù)業(yè)務(wù)流程：

   • 保單微服務(wù)完成保單數(shù)據(jù)保存后，會觸發(fā)一系列后續(xù)的領(lǐng)域事件，推動業(yè)務(wù)流程在傭金、收付費、再保等微服務(wù)之間流轉(zhuǎn)。

---

領(lǐng)域事件驅(qū)動的優(yōu)勢

1. 解耦微服務(wù)：通過領(lǐng)域事件，微服務(wù)之間的依賴關(guān)系被弱化，發(fā)布方和訂閱方可以獨立演化。

2. 提升系統(tǒng)性能：領(lǐng)域事件采用最終一致性，減少了分布式事務(wù)的使用，提升了系統(tǒng)的性能和可擴展性。

3. 支持復(fù)雜業(yè)務(wù)流程：領(lǐng)域事件可以支持復(fù)雜的業(yè)務(wù)流程，尤其是在跨多個微服務(wù)的場景中，事件驅(qū)動的方式可以簡化系統(tǒng)的設(shè)計和維護。