CQRSはEvent Sourcingなしで実現できるのか？
先日のBPStudy 151で以下のテーマで話しました。
CQRSはCommand and Query Responsibility Segregationの略で、日本語ではコマンド・クエリ責務分離。2010年にGreg Young氏が考案したパターンです。興味あれば CQRS Documents by Greg Young を読んでみるとよいかもしれません。和訳もあります。
拙作のスライドですがこれだけ読んでも概要はつかめると思います。
CQRSはEvent Sourcingなしで実現できるのか？
結論からいうとEvent Sourcingがなければ現実的ではありません。なので必須と考えてよいです。背理法的な思考でシミュレーションしてみましたが、ステートだけに基づくと必ず行き詰まります。詳しい理由は一番上のスライドみてもらえば分かります。
WriteDBへの状態更新とReadスタックへの通知は二つのDBを使って書き込むと「二層コミット問題」が生じます。これを回避するにはEvent Sourcingのように先にイベントを永続化し、その後に永続化されたイベントを読んでRead系に通知する必要があります。
今回、新しく紹介した、CDC+Outbox方式でも上記の問題は回避できます。都合がいいことにステートの管理だけで済むように見えますが、これはトランザクションログを使ったイベントソーシングと言っても差し支えありません。つまるところ、最新状態を作れたとしても、真のデータソースになりません…。
ということで、CとQを完全に分けるのがCQRSなので、それなりに仕組みが必要です。CDC+Outboxでやりたければ、Debeziumは良い選択肢になると思います。
CDC+Outboxについて興味があれば以下の記事も読んでみてください。
この記事が気に入ったらサポートをしてみませんか？