要約
(1) 参照系の要件はもっぱらデータ資源利用側から発せられ、更新系の要件はもっぱらデータ資源提供側から発せられる。
(2) よって、もし「フロントエンド・アプリ」と「バックエンド・サービス」とに階層分けするならば、参照系は「フロントエンド・アプリ」が装備すべきで、更新系は「バックエンド・サービス」が装備すべきである。
(3) 以上のように分離された参照系と更新系は、同一データ資源を扱っていても、もはや異なる境界付けられたコンテキストに属すると云うべきである。
(4) DDDにおける「CQRS」は、参照系と更新系が異なる境界付けられたコンテキストに置かれるとした場合の設計アプローチに関する論だと捉え直すことができるのではないか。
◇
参照系と更新系の非対称性について気付いたのは、かつて「ROA」と「SOA」の差異の本質は何なのかを考えた時でした。
ROAでは、リソースを比較的“裸”に公開して、アクセスAPIは単純CRUDであることが推奨されていました。SOAではリソースを“裸”で公開することは決してなく、公開するものは「処理」でした。時代順序としてROAが後から出てきて、かつSOAがSOAPという重い実装と関連付けられていたことから、ROAは、「SOAのようにいちいち“サービス”を挟むのはオーバースペックで、シンプルな（≒RESTfulな）APIで十分である」というような「SOA批判」がコンセプトの中核かのように認識されていました。
実はROAは、「フロントエンド・アプリ」と「バックエンド・サービス」とを分けて捉えるなら、「フロントエンド・アプリ」の側から出てきたコンセプトでした。いえ、そもそも「フロントエンド」というレイヤー、もっと云ってしまえばフロントエンドという“サブドメイン”が明確に意識されたのは、エンタープライズに対するいわゆる「Web系」の発展著しいところからです。Web系のシステムは旧来のエンプラの典型に比べて、圧倒的に参照処理過多という特性をもっています。かつ要求仕様変更頻度が相対的に高いという特性もありました。対してバックエンドは旧来のエンプラの特性をそのまま引き継いでいると云えます。フロントエンドとバックエンドを分けるなら、SOAはもちろん「バックエンド・サービス」側から出てきた提案だということになります。
そのような「フロントエンド・アプリ」にとって、要求仕様変更の都度毎回毎回バックエンド・サービスに手入れをしなければならない、というのはあまりにも非生産的でした。単純CRUDで公開して貰えばあとは好きにする、という発想は当然なものでした。（※この動きにRails（Active Record）系の人たちも同調したと云えるでしょう。）
そのような動きに対して「バックエンド・サービス」の立場（←私が立つところ）としては、次のようなジレンマを抱えることとなりました。「フロントの云うことはよく分かる。とはいえ、無防備にCRUDを提供するだけというのでは、当初サービス層を設けて、業務ロジックの運用性・保守性を高めようとしたコンセプトはどうなるのか」、と。
「バックエンド・サービスには意味があるはずだ」という自分たちの確信はありました。一方、フロント側からの柔軟さの要求も否定することはできません。ここの構造ギャップに潜むものは何か、考えました。そして次のようなことに気付きました。
・フロントエンド側の要求はほとんど参照処理である。
・バックエンド側の要求は突き詰めれば、業務プロセスや業務データの一貫性を破綻させるような更新処理から、データを守りたい、という点に絞られる。（※参照処理については、各種のアクセス制御を行うこと以上には強い要求はない。）
つまり、「バックエンド・サービスとしては、更新処理さえサービス提供できれば、参照系の処理はフロントエンド・アプリに渡すことができる、否、渡すべきだ」、という結論に至ったのです。
もう一つ重要な認識があります。ここで挙げたような状況にある参照系を担うフロントエンドと更新系を担うバックエンドは、異なるサブドメインもしくは境界付けられたコンテキストにあると云うべきだろう、ということです。なぜなら、同一データ資源を対象にしているようでも、もはや異なるモデルを描いているからです。異なるモデルを想定するなら、定義からして境界付けられたコンテキストは異なります。
さらにもう一点言及しておくべきは、「CQRS」とは、参照系と更新系が異なる境界付けられたコンテキストに属するというような場合にどういった設計を取ることができるか、という観点から捉え直すことができるだろう、ということです。
◇
＜追記＞
よろしければ下記関連記事もご参照ください。
◆以上
