こちらの記事で、サーバーとクライアントがDTOのやりとりをしている時点でドメイン知識は失われているという話をみた
元の話はCQRS を考案した Greg Young 氏の以下のドキュメントによるもの
https://cqrs.files.wordpress.com/2010/11/cqrs_documents.pdf
クライアントから送られてくる DTO をバックエンドで受け取ったやつは、もはやビジネスロジックとドメイン知識が失われているという話
それをCQRSが解決するというのだが
もう少しこのあたりを調べてみる
CQRS自体については以前調べたことがある
書き込みと読み取りでは関心事が違うのでわけて考えようというのがCQRS
従来のCRUDって、C=作成する、R=読み込む、U=更新する、D=削除するの４つのあいまいな動詞しか定義できないのでDDDに不向きと言われている
そこで、データをどうこうではなく、サーバーにコマンドを送信して何をするか伝えるようにしてみる
それにより「ChangeAddress」や「CreateUser」「DeleteClass」のような名前のメソッドをすぐ作成しがっちだったものが、ちゃんとドメインイベントに沿った命名ができる
これがCQRSの解決ものの一つ
クライアントサイドでもこのアーキテクチャで考えようとする@azuさんの記事があった
Almin.jsは今度調べてみる
他参考
CQRS+ES(再)入門 - Speaker Deck
docs.microsoft.com
http://www.minato.tv/cqrs/cqrs_documents_jp.pdf
