CQRS/ESを使うべきではないケースは、どのようなものがありますか？

CQRS/Event Sourcingを使用する理由は以下のようなものです。 - パフォーマンスの最適化：読み取りと書き込みの操作が異なるモデルやデータストアを使用できるため、それぞれを最適化することが可能です。例えば、書き込みモデルはトランザクション処理に特化し、読み取りモデルは高速なクエリ応答に特化できます。 - スケーラビリティの向上：読み取りと書き込みのコンポーネントを独立させることで、それぞれを別々にスケーリングすることができます。これにより、リソースをより効率的に利用し、システムの全体的な処理能力を向上させることができます。 - 複雑性の管理：CQRSは、ビジネスロジックをより単純で管理しやすい形に分離することにより、システムの複雑性を減らすのに役立ちます。 - セキュリティと安定性：書き込みと読み取りの処理を分離することで、セキュリティリスクを軽減し、システムの安定性を向上させることができます。 - 柔軟性と保守性：異なるモデルを使用することで、将来の変更や拡張が容易になり、システムの保守性が向上します。 というのが教科書的な説明ですが、考案者のGregさんは以下のように言っています。 > The application of Domain Driven Design is not possible in the above architecture though many who are “practicing” Domain Driven Design use this architecture. The reasoning for why it is impossible can easily be seen when one looks at how the Ubiquitous Language is represented by the object model. > ドメイン駆動設計を実践している多くの人は、先述のアーキテクチャを使用しますが、このアーキテクチャではドメイン駆動設計 のアプリケーションは不可能です。なぜ不可能なのかという推論は、ユビキタス言語がどのようにオブジェクトモデルを表現する のかを見れば、簡単に導くことができます。 先述のアーキテクチャとは非CQRSスタイルのことです。言い切ってますね。 これをもう少しかみ砕くと以下のようなことです。この資料の62ページから66ページまでをみてください。 https://speakerdeck.com/j5ik2o/ikanikai-fa-xiao-lu-topin-zhi-wogao-meruka-domeinqu-dong-she-ji-tozu-zhi-patannoshi-dian-karakao-eru?slide=62 ドメインモデルとリポジトリを使って複雑なクエリ要件を実装する際に、破綻が起きることが分かると思います。 逆にいえば、クエリ要件がそこまで複雑なものがない&非機能要件もそれほど高くないのであれば、CQRS/ESは不要かもしれません。