技術層面的資料DTO需要轉化為領域層的Domain物件

CQRS是一種將命令和查詢分離的模式或架構,因此Command物件是CQRS的重點。命令表達了使用者的意圖,使用者希望計算機系統做他想做的事情。命令透過傳送請求到達計算機系統,使用者透過響應知道他的命令是否被計算機成功執行。命令來源於請求,請求涉及到HTTP請求或訊息請求等計算機技術。請求的技術形式很多,在應用服務層需要將命令與請求分開,因為請求中的資料基本都封裝在了失血DTO資料傳輸物件中,因此,技術層面的資料DTO需要轉化為領域層的Domain物件。

技術層面的資料DTO需要轉化為領域層的Domain物件

這些作業屬於應用層邏輯,在應用層完成。傳遞給領域層的資料被封裝成命令物件的形式,所以領域層所依賴的輸入資料不再是DTO,因為DTO屬於技術層面,如果領域模型的輸入引數依賴於DTO,會導致領域層對技術層的依賴與領域驅動設計的宗旨背道而馳。這就是領域驅動和資料驅動的區別。傳統的三層架構包括表示層、應用層和儲存層。表示層依賴於應用層,應用層依賴於儲存層。因此,實體物件、DTO物件或資料庫成為依賴的核心,這是資料驅動架構的典型特徵。。領域驅動設計應該以領域模型為核心。清潔架構、六邊形架構和洋蔥架構提供領域驅動的實現架構。

技術層面的資料DTO需要轉化為領域層的Domain物件

整個系統從以資料庫模型為核心到以領域模型為核心的轉變並非一帆風順,因為資料驅動的設計已經深入人心。可以說是一種簡單的入門級設計方法。即使在領域驅動設計的實踐中,他們也會無意識地使用資料驅動設計。CQRS的好處之一是領域驅動設計和資料驅動設計的分離。資料驅動設計可以用在查詢讀取模型中,而領域驅動設計必須用在命令傳入執行的模型路由中。因此,從請求的起點開始,沿著請求的傳入方向,逐一檢查請求的各個環節,確保請求資料在傳遞給領域層之前已經轉化為命令物件。

技術層面的資料DTO需要轉化為領域層的Domain物件