API設計とCQRS

Question

CQRSという考え方があります。クエリとコマンドを分離するという考え方です。
APIの中でもDBにデータを格納する際にPOSTを利用してデータの格納かつ、そのレスポンスをフロント側へ返すというケースをよくみるのですが、これはCQRSの考え方に反しているのでしょうか？
具体的に言えば、あるIDをDBへ格納し、格納したIDをフロント側へ返すAPIがあります。
格納したIDを後ほど利用したいのでこのようにしています。
本来であれば、IDを格納するAPIと格納したIDを取得するAPIは別にするべきなのでしょうか？

Answer 1

まったく同じ質問があります。

In CQRS, how do you generate a correct autonumbered ID? - stackoverflow

個人的にはAlexander Langersさんの回答に同意します。
インフラストラクチャ要件がフロントの設計に影響を与えるのは、保守性や変更容易性の観点から言えば好ましくありません。

Comments

[ccccuuurrryyy]

引用までしていただきありがとうございます。
"インフラストラクチャ要件がフロントの設計に影響を与える"についてもう少し具体的に教えたいただけないでしょうか？

[gentaro]

「データベースによって採番されるID」というのは、ドメインモデリング上は登場しないはずです。
ましてや、そのIDがフロント側で必要になるケースというのは、フロント側ががっつりインフラストラクチャであるDBに依存した形になってしまいます。
例えばですが、データベース上のIDを当初32bit整数型で定義してた場合、レコードの増加に従って64bit整数型に変更したくなるケースを考えてみてください。
本来この修正はインフラストラクチャ層であるデータベースと、そこと直接やりとりするアプリケーション側のコードの修正だけで済ませられるはずが、フロント側にまで「DBのID」を露出させてしまうと、フロントも影響範囲に含まれて修正する必要が出てきます。
このように無駄に影響範囲を広げるのは好ましくない、ということです。

[ccccuuurrryyy]

ご説明いただきありがとうございます。
IDがデータベースによって採番されるのではなくアプリケーション側でランダムに生成しているものの場合は別にするべきなのでしょうか？

[gentaro]

コマンド実行後にそのエンティティのIDが必要なのであれば、IDをGUID型にしてコマンド発行側がIDを新規に生成し、一緒に渡せば良いんじゃないでしょうか。
コマンドそのものが値を返すのは、エンティティの作成とIDの取得という２つの責務を負わせてしまっているため、どうかと思います。
IDが内部情報ではなく、エンティティの属性の一部という扱いをしたいのであれば、エンティティの他の情報と同じく、コマンド発行側が指定して一緒に渡すのが自然だと思います。
かといって、他に必要に応じてIDを取得するという単体の需要があるならともかく、今回のように単一の処理単位であるべきのものを２つに分割するのが良いようにも思えません。

Answer 2

格納したIDを後ほど利用したいのでこのようにしています。

IDをデータベース側で自動で振るようにしている場合、挿入結果のIDはデータを挿入した直後に取るのがいちばん確実なので、無理に別にわけないほうがいいです。

Comments

[ccccuuurrryyy]

ID自体はアプリケーション側でランダムに生成しているものになります。ランダムに生成したものをDBに格納している形です。
この場合も同様でしょうか？

[maisumakun]

> ID自体はアプリケーション側でランダムに生成しているものになります。

そうだったのですね…失礼しました。

[ccccuuurrryyy]

この場合は分けた方がいいということになるのでしょうか？

[maisumakun]

すみません、その場合についてはコメントできないです。

[ccccuuurrryyy]

承知しました、コメントありがとうございました！