我們可以一起使用REST + Event Sourcing + CQRS

Question

我瞭解REST + Event Sourcing的基礎知識。 我從來沒有在嚴格的RESTful API上工作，也沒有在任何Event Sourcing項目中工作過。

有人可以解釋，如果兩者都可以一起使用？

在事件源代碼中，客戶端發送事件，這是否意味着在服務器上有一個單一的事件集合，並且該API的所有POST都將在該集合上，以向其添加事件？

客戶端如何發現它可以發送給服務器的命令？

Answer 1

簡短的回答 - 是的，我們可以。

所有你列舉的東西，我的意思是REST，ES和CQRS是爲了不同的目的。 所以我沒有看到任何問題一起抓住它。

讓我們看看 - REST是一種實現Web服務API的方式，ES是一種在域內進行通信的工具，而CQRS則作爲中級體系結構。

那麼，在ES中，客戶端（如果我們在談論Web客戶端）不會發送域事件。如果你的意思是另一個BC，而BC是你的域名的一部分，我想運輸事件應該以另一種方式來解決，一個服務總線或類似的東西將是greate。如果BC不屬於您的域名，您應該通過ACL和API進行溝通，而不是原始域名事件。 :)

有關命令的簡短說明。再次，在CQRS中，命令位於應用程序邊界內。外部客戶端（Web客戶端，API客戶端）不應該有能力直接發送應用程序命令。您應該提供一個API（內部客戶端），它允許執行某些服務的用例，但不能提供單個和單獨的命令。對於一個自制的例子，你可以嘗試得到一個非常受歡迎的SO問題的答案 - 當我們使用CQRS時如何檢查用戶名不唯一？ :)

Answer 2

有人可以解釋，如果兩者都可以一起使用？

是的。客戶端（瀏覽器）只是做它想做的事情，（http）服務器可以將這些行爲記錄爲事件。

在事件源中，客戶端發送事件，這是否意味着在服務器上有一個單一的事件集合，並且API的所有POST都將在該集合上向其添加事件？

不可以。客戶端可以是事件的發起者，但不應該知道什麼構成事件以防止基於事件集合的服務器和客戶端之間的緊密耦合。事件採購應該被封裝，並且不會被演員隱藏。

客戶端如何發現它可以發送到服務器的命令？

如果您不需要在上一個問題中建議的相同集合上發送事件，則這不是必需的。您可以以任何您想要的方式簡單發佈REST API，並隱藏客戶/演員的事件採購。看看http://restdesc.org/。

Answer 3

REST是一種傳遞方法，它決定了你的應用程序的接口。大多數情況下，REST使用REST一致性模型，但它可以通過響應命令來支持最終的一致性模型。

事件源是一種通用的數據存儲機制。您通常使用事件源採用最終一致性模型以及域驅動設計，命令和查詢隔離，但它可以通過多階段提交來支持即時一致性模型。

它們在您的應用程序中解決了完全不同的事情，它們彼此兼容，因此您可以一起使用它們。

由於事件採購，客戶端發送事件，這是否意味着在 有事件和 API的所有帖子的單個集合將在該集合，事件添加到它的服務器？

您完全誤解了這個概念。您可以將事件序列存儲在事件存儲中。事件是狀態的變化，所以如果你存儲你的應用程序的每一個狀態變化並以正確的順序重放它，那麼你可以重新創建應用程序的當前狀態。這非常好，因爲您可以簡單地通過重播事件並將其轉換爲數據庫查詢來將數據遷移到另一個數據庫。您可以使用常規數據庫創建查詢緩存。因此，您的客戶可以讀取該查詢緩存，而不是總是從理由重新創建當前狀態。

事件通常不是由客戶端創建的。通過域驅動設計，您的域邏輯通過處理命令創建域事件。

客戶端如何發現它可以發送到服務器的命令？

REST客戶端使用鏈接發送請求到REST服務。 REST服務可以處理這些請求並將它們轉換爲命令和查詢。這些命令由域邏輯處理，並且會導致域事件的發生。查詢被轉換成查詢查詢緩存的數據庫查詢。