何問!
エンタープライズ アプリケーションのイベント ストレージ スコープとは正確には何ですか?
イベント ストレージは適切なパターンではありません。これは通常、イベント ソーシングとコマンドとクエリの責任分離という 2 つの異なる (ただし強く関連する) パターンで使用される手法です。「ストレージ」であるため、ビジネスに関連するアプリケーションの状態を永続化する方法にすぎません。
どちらのパターンもドメイン駆動設計で Evans によって導入されたパターンとうまく機能するため、ドメイン モデルと組み合わせて使用されることがよくあります。
EventStore を使用すると、ドメイン イベント (イベント ソーシングの方法) またはアプリケーション イベント (別名、CQRS のコマンド) を永続化できます。モデルの状態を保存するのではなく、モデルにつながったイベントを保存するため、ドキュメント ストレージやリレーショナル ストレージとは異なります。ただし、RDBMS またはドキュメント データベースのいずれかを使用してイベントを格納できます。
次に、エンティティを取得するには、登録されている各イベント/コマンドを順番に再生します。スナップショットを使用すると、このプロセスを高速化できます。
イベント ストレージは複数のプロセス間で共有されますか?それともプロセス内の概念にすぎませんか?
ストアの実装に依存しますが、複数のプロセスやアプリケーション間での使用を妨げる理由はありません。
アプリケーションを閉じると、イベントはどうなりますか? それらはアプリケーションの「インスタンス」またはアプリケーションにバインドされていますか?
ここでも、ストアの実装に依存します。最も単純なイベント ストアは、イベントを番号付きのファイルに保存します。したがって、アプリケーションがシャットダウンしても、イベントはそこに残ります (これは、常に Thompson の言葉を思い出させます:「永続オブジェクトがあり、それらをファイルと呼びます」)。
ただし、アプリケーションが本当に必要とする場合は、揮発性のイベント ストアをメモリ内に保持することを妨げるものは何もありません。エントリの順序を維持する追加専用のコレクションとして実装します。
イベント ストレージとパブリッシャー/サブスクライバーを使用した MessageBus の違いは何ですか (メッセージ履歴を保存できるという事実の一部は?
メッセージ バスは、メッセージを配信するためのツールです。イベント (およびコマンド) はメッセージであるため、イベントを配信するために使用できます。代わりに、イベント ストアは永続化ツールです。
メッセージの冪等性の責任者は誰ですか?
最も一般的なシナリオでは、ドメイン モデルを設計する担当者です。非 DDD システムでは、メッセージ (イベントまたはコマンド) を設計するのは担当者です。実際、冪等性は、テクノロジー自体ではなく、メッセージの受信者によって保証されなければなりません。
そのため、EventStore は、重複したメッセージを検出したときにそれらをマージできます。しかし、これ自体がモデルを冪等にするわけではありません。
この文は実際には何を意味していますか:"興味深いことに、メッセージ キューや永続ストレージなど、関連するさまざまなリソースに分散トランザクションが存在しなくても、EventStore は完全なトランザクション エクスペリエンスを保証できます。これは、分割することによって実現されます。分散トランザクションを小さな断片に分割し、それぞれを個別に実行する" (このプロジェクトから) トランザクションをいくつかの小さな断片に分割する方法が理解できません。
それは、著者が「完全な取引体験」に割り当てる意味に依存します。私には、この文は間違っているように見えます。ブリューワーの定理が破られるからです。
Microsoft と Greg Young によるこのCQRS Journeyが役に立ちます。
明日、オフィスでお会いしましょう :-)