cqrs

Xendor

Xendor是一個.NET核心框架，可通過執行單一的責任和分離關注點來創建簡單明潔的設計。它的高級功能非常適合域驅動設計（DDD），命令查詢責任歸屬（CQRS）和事件採購。 Xendor還具有RabbitMQ集成。

什麼是CQR？

命令匯率責任隔離是一種告訴我們將數據與查詢數據相關的操作的模式。它是從命令查詢分離（CQS）CQS派生的，在類上只有兩種方法：突變狀態和返回void的方法以及返回狀態但不會更改的方法。

CQRS是您應用的模式嗎？內部？您的服務/應用程序，您只能將其應用於服務的部分。

那不是CQRS

最終不是一致性

不是發生

這不是消息傳遞

它沒有分開的讀物模型

它也不使用事件採購。

CQRS Pros＆Cons

優點：

• 系統的性能和可擴展性更好。
• 更好的並發訪問處理。
• 更好的團隊可擴展性。
• 不太複雜的域模型和簡單的查詢模型。

缺點：

• 讀寫模型必須保持同步。
• 維護和管理費用，如果您選擇兩個不同的引擎進行閱讀和寫作方面。
• 最終並不總是允許的。

什麼是事件採購？

與其僅將數據的當前狀態存儲在域中，不如使用僅附錄存儲來記錄對該數據採取的完整動作。該商店充當記錄系統，可用於實現域對象。這可以通過避免同步數據模型和業務領域的需求，同時提高性能，可擴展性和響應性來簡化複雜域中的任務。它還可以為交易數據提供一致性，並保持完整的審計跟踪和歷史記錄，以實現補償措施。

在哪個系統中值得使用事件採購？

• 您的系統具有許多不是普通cr的行為。
• 重新創建物體的歷史狀態非常重要
• 企業用戶看到有關統計，機器學習或其他目的擁有完整歷史記錄的優勢。
• 事件最好描述您的域（例如，跟踪援助車輛活動的應用程序）。

活動採購利弊

優點：

• 僅附加模型非常適合性能，可伸縮性
• 沒有僵局
• 事件（事實）是商業專家對事件的理解，有些域本質上是事件來源：會計，醫療保健，交易
• 免費審核步道
• 我們可以在任何時間點獲得對象狀態
• 易於測試和調試
• 與域模型分離的數據模型
• 沒有阻抗不匹配（對像模型與數據模型）
• 靈活性？許多不同的域模型可以從相同的事件流構建
• 我們可以將此模型與反向事件，追溯事件一起使用
• 沒有更多的ORM？由於我們的對像是由事件構建的事實，我們不必在關係數據庫中反映它

缺點：

• 開發人員管理狀態和構建聚集體不是自然的方式，需要時間來習慣
• 查詢超出一個匯總有點困難（您必須針對要添加到系統的每種類型的查詢類型的預測），
• 事件模式變化比關係模型（缺乏標準模式遷移工具）要困難得多）
• 您必須考慮從一開始就進行版本處理。

事件採購 - 預測

在構建以事件為中心的系統時，投影是一個重要的概念。同時，這非常簡單。

投影是關於從事件流得出當前狀態的。

例如，考慮一種情況，服務器向所有訂戶發布了一系列事件。這些事件與用戶註冊有關，看起來像：

UserAddedToAccount

{
 "userId" : 55 ,
 "username" : " alemol " ,
 "name" : " Alejandro " ,
 "lastName" : " Moline "
}

UserverifiedEmail

{
 "userId" : 55 ,
 "email" : " [email protected] "
}

用戶求婚

{
 "userId" : 55 ,
 "lastName" : " Molines "
}

我們可以將訂戶附加到這些事件的流中，以將此流將其投影到持續的讀取模型中，用於在Web UI中提供用戶詳細信息。最終讀取模型看起來像：

{
 "userId" : 55 ,
 "username" : " alemol " ,
 "email" : " [email protected] " ,
 "name" : " Alejandro " ,
 "lastName" : " Molines "
}

帶有事件採購的CQR（CQRS-ES）

給星星！

如果您願意或正在使用此項目，請給它星星。謝謝！

我找到了問題，或者有更改請求

隨意在Github上創建問題。貢獻，拉力請求非常歡迎！

Xendor是版權所有©2019 Alejandro Molines和MIT許可下的其他貢獻者。