CQRS中命令可以返回值嗎？ -OSKAR

banq發表於2021-03-12

CQRS中通常建議命令的處理要"乾淨"，實際上將其視為“無效函式void”。這種函式不返回任何業務結果，但可以返回操作狀態或所需的後設資料。
在CQRS中，命令和查詢的隔離基於操作行為。查詢返回資料，並且不更改應用程式的狀態；命令修改狀態。這種隔離有助於建立鬆散耦合的元件，不斷髮展的解決方案，並透過專注於特定任務，可伸縮性等來減輕程式設計師的認知負擔。
是否有一種用例可以證明從命令處理中返回值是合理的？當然，我們不應該返回任何資訊，因為客戶端已經知道了他發出的命令。客戶端不知道的是在伺服器端生成/計算的資料。通常，它這些資料是後設資料，例如修改日期，版本，有時還包括業務資料（例如新記錄狀態）。
我們可以返回更新期間的物件識別符號ID，然後，我們可以執行查詢命令來獲取更新後的資料後，也就是查詢需要的讀取模型資料。新物件的建立很複雜，除非我們返回客戶端生成的識別符號ID，否則客戶端就不會知道建立了哪個記錄。
 

CQRS與API
我們必須記住，我們可以從兩個角度看待我們的應用程式：

  • 邏輯-顯示我們如何劃分和組織業務程式碼。
  • 技術-描述如何組織特定的實施方式，例如儲存結構，部署等。

CQRS代表邏輯檢視，API代表技術檢視。它們不必相同，我們可能需要將一個概念對映到另一個概念。如果我們正在使用REST API，則在處理了建立新記錄的命令之後，我們想返回帶有識別符號的201狀態。如果錯誤是由業務邏輯引發/返回的，我們希望獲得特定的HTTP錯誤型別。
我們必須做出務實的決定。我認為，CQRS命令返回ID或狀態或與我們觸發的行為相關的任何其他所需的後設資料都是可以的。當然，我們應該小心謹慎，並始終確保需要這種妥協。如果我們濫用它，那麼CQRS的關鍵要素-隔離充其量將是紙面上的契約。
這不僅會影響程式碼的純度和耦合性，還會影響效能和可伸縮性。讀取模型可以由不同的節點，儲存引擎，負載均衡等處理。
我們必須記住，命令本身並沒有告訴我們它進行了哪些具體更改。它沒有定義將新增，更新還是刪除記錄。而且，它還不能確定更改是否會影響哪一條記錄或更多其他記錄。即使是單個更改，也可能涉及重新整理幾個讀取的模型（例如，確認訂單會更新使用者的訂單列表，賣方管理皮膚，通知檢視，訂單歷史記錄等）。所有這些都是由處理命令的業務邏輯定義的，而不是由命令本身定義的。命令代表意圖，而不是其處理方式及其產生的影響。
如何使用REST處理CQRS？通常，我嘗試將WebAPI合同與命令和查詢定義分開。我將WebAPI視為反腐敗層。在控制器方法中，我可以生成一個識別符號並基於該識別符號建立命令。然後，可以將相同的識別符號返回到“建立”狀態。

 

相關文章