CQRSアーキテクチャの最適化とバリエーション

Question

コマンドクエリの責任分離/イベントソーシングアーキテクチャは、私が始めようとしているプロジェクトにはっきりと適合しています。主な利点は、監査履歴、スケーラビリティ、多数のチーム間で非同期互換UIを実施し、これらのトランザクションを読み取りデータベースから分割し、イベントキューを介して断続的に接続されたフィールドオフィスへの状態の伝達を容易にし、重要なビジネスロジックの変更に対処することですシステム全体の寿命を通じて。

しかし、CQRS/ESが問題になる領域があります。例えば、1億人に数値IDを割り当て、最終的な一貫性が受け入れられないユーザーセキュリティなどです。また、本質的にCRUDであり、CQRS/ESの恩恵を受けないシステムの領域もあります。最後に、さまざまなチームや企業に多数の開発者を迎え、CQRS/ESコンピテンシーを必要としない分野を持つことは良いことです。ハイブリッドアプローチを採用することは可能ですか？一部の地域はイベントソースではありませんか？関連するテーブルを読み込み側と書き込み側の両方で同期させることはできますか？

CQRSアーキテクチャの集約エンティティは、スナップショットキャッシュの無効化を簡素化しますか？キャッシュされる可能性のある集約エンティティを更新するイベントは、無効化されたエンティティによってリッスンされる可能性があり、集約エンティティはリレーショナルエンティティよりも粗く、書き込みイベントを区別できるため、この問題は解決できますか？

私は約10億回のイベントを予定しており、約4年間の歴史を追跡する必要があります。古いイベントをスナップショットやアーカイブできますか？

イベントソーシングの度はありますか？たとえば、1つのオンラインストアシステムAddLineItemイベントには、ユニットあたりの広告申込情報の価格が含まれていますが、請求先の商品名をプル＆レンダリングするには、読者側に依頼してください。別のオンラインストアは、イベントデータに名前を含めることができます。どのようにイベントに含めるかを選択しますか？健康保険では、もし何の場合に分析が実行できるのかを制限するかもしれません - 被保険者の年齢を含めなければ、それを必要とする政策を実現可能にシミュレートすることはできません。

イベントに関するイベントをモデル化する興味深い方法はありますか？たとえば、管理者は、将来、ある日に製品の価格が変更されることをシステムに入力します。スナップショットは価格のタイムラインになると思います。更新されたProductPriceChangedイベントを追加することはできますか？ 「もしかしたら」シナリオを実行するときに、そのような出来事を偽ってもらえますか？

CQRS/ESは、システムを将来のビジネスプロセスの変更に容易に適応させるために、しばしば主張されています（この集計は、バージョン番号と並行性検出の問題を回避するためにほとんど変更されません）。私は、ユビキタス言語でイベントをリストするコマンドは、それらの議論や再構成を容易にし、イベントソーシングはRDBMSモデルのいくつかの剛性を取り除くという議論を理解しています。しかし、何も変更されません以内にイベントは、イベントの再生を中断させますか？システムが変更されると、多くのバージョニングされたイベントは終了しませんか？たとえば、クライアントが基準を変更してゴールドカードホルダーであるかどうかを評価するオンラインストアでは、すべてスナップショットできますか？これらの変更をどのようにポストデートしますか？同様に、注入された依存関係のどれもがビジネスロジックに影響を与えることはありません。そうでなければ再生を中断するように、依存性注入に注意する必要がありますか？

なぜそれが.NETの世界に関連しているのか、業界の他の分野ではあまり人気がないのですか？

巨大なちょうど読書のためにありがとう。

Answer 1

いくつかの領域がイベントソースではないハイブリッドアプローチを採用することは可能ですか？

もちろんです。

読み込み側と書き込み側の両方で関連するテーブルを同期するだけでいいですか？

多くの場合、これは悪い考えです。

CQRSアーキテクチャの集約エンティティは、スナップショットキャッシュの無効化を簡素化しますか？

あまりですか？キャッシュを無効にするために使用できる記録簿に書き込みが発生したという事象が存在するという考え方は、特にCQRSの考え方ではありません。いずれにしても簡単なことではありません。

古いイベントをスナップショットでアーカイブすることはできますか？

はいしかし...それは短いエピソードに分割されている長命エンティティの歴史の観点から考えることは通常より簡単だし、1つのエピソードから次へと状態ロールオーバー - 例えば、寝返りを検討財務期間の終わりには元帳。次に、人生の終わりである集約の履歴をアーカイブします。

どのようにイベントに含めるかを選択しますか？

ビジネスインバリアントを確立/維持/復元するために、この集約に必要な状態を確認してください。他のすべてが洗濯に行くことができます。これはしばしば、レポート（読み込みモデル）が複数の集約から、そして場合によっては文書からもアセンブルされることを意味します。

イベントに関するイベントをモデル化する興味深い方法はありますか？

イベントに関するイベントは面倒です。 のイベントのイベントはすばらしいです。

代わりに、日付が付いたProductPriceChangedイベントを追加できますか？

間違ったスペル - 試してみてくださいPriceChangeScheduled。注：モデリングの時間は重要です。ドメインモデルは、外部の世界が言及しない限り、時間の経過に気づくべきではありません。

ただし、イベント内の変更によってイベントの再生が中断されることはありませんか？

いいえ、しかし、これがそうであることを保証するためにイベント表現について維持する必要がある分野があります。グレッグ・ヤングは電子書籍としてVersioning in an Event Sourced Systemと書いています。

スキーマのクイックフィールドとダーティフィールドはオプションです。それらを追加したり削除したりすることはできますが、その意味を決して変更することはできません。コンシューマーは、読みたいものにはデフォルト値を提供し、理解していないエントリーは「無視する」必要があります。

システムが変更されると、バージョン管理されたイベントは終了しませんか？たとえば、クライアントが基準を変更してゴールドカードホルダーであるかどうかを評価するオンラインストアでは、

これはどの質問になりますか？イベントのいくつかの表現があるかもしれません（どのスキーマが予想され、どのデフォルト値が考慮されるかによる）が、それはただ一つのイベントです。システムによって行われた決定はイベントによって記録されるため、時間の経過とともにバージョン管理は実際には入りません。

同様に、挿入された依存関係のどれもビジネスロジックに影響を与えないように、依存関係注入に注意する必要があります。

ビジネスロジックはすべてドメインモデルに存在し、ドメインモデルはタマネギの中心に存在します。現実の世界から切り離されている。したがって、現実世界に副作用をもたらす依存性を注入するべきではありません。これらは通常、非同期で処理されます（これらのイベントを正常に保存したため、副作用をスケジュールできます）。

業界の他の分野で人気が低く、.NETの世界に関連付けられている理由は何ですか？

人。 Udi DahanとGreg Youngはどちらも.NETのバックグラウンドを持っています。 Mathias Verraesにはその背景があるので、PHPでも人気があります。

非ES集約エンティティをどのように保持することをお勧めしますか？

ドキュメントストア？ RDBMS？フラットファイルですか？多言語の永続性は問題ありません。

これは、この不具合の解決方法を紛失する可能性があります。ビジネス不変式がオーダー明細である場合、商品名または価格だけが含まれますか？

おそらく製品IDと数量で十分です。見積もりがカタログに記載されているものと異なる可能性があるビジネスの場合は、おそらく価格見積もりです。

つまり、集約のビジネスロジックは変更されますが、過去のイベントでは古い方法を処理する必要があります。

重要なアイデアの1つは、イベントの意味が変わらないことです。彼らは国家の変化を記述している。したがって、「新しいバージョンのイベント」が異なるものを意味する場合、実際には新しいイベントが発生します。ヤングの本を参照してください。

集約ビジネスロジック - ある状態から次の状態への進化の仕方を決定します。それは変化する。しかし、与えられた集合体が実際にどの状態にあるかは変わりません。

たとえば、状態によっては到達できないことがあります。それはビジネスロジックです。集合体はその状態で終わるために新しいイベントを書き込むべきではありません。これは、現在到達不能な状態にある集約には何ら影響しません。彼らは歴史がそこに置かれているので、彼らはまだそこにいます。あなたは彼らにもっと多くの出来事を与えて、その状態から外に出ます。