タグ付けされた質問 「event-sourcing」

私は最近、職場で適用する必要があるかもしれないので、CQRS / ESに飛び込み始めました。多くの問題を解決するため、私たちのケースでは非常に有望です。 ES / CQRSアプリが、単純化された銀行のユースケース（出金）にコンテキスト化されたように見える方法についての大まかな理解をスケッチしました。 要約すると、Aがお金を引き出した場合： コマンドが発行されます 検証/検証のためにコマンドが引き渡される 検証が成功した場合、イベントはイベントストアにプッシュされます アグリゲーターはイベントをデキューして、集約に変更を適用します 私が理解したことから、イベントログは真実の源であり、FACTSのログであるため、それから予測を導き出すことができます。 さて、この壮大な計画の中で私が理解できないのは、この場合に何が起こるかです： ルール：残高をマイナスにすることはできません 人Aのバランスは100eです 人Aは100eのWithdrawCommandを発行します 検証に合格し、100eイベントのMoneyWithdrewEventが発行されます その間に、人Aは100eの別のWithdrawCommandを発行します 最初のMoneyWithdrewEventはまだ集約されていなかったため、検証は合格です。これは、集約に対する検証チェック（まだ更新されていないため） 100eのMoneyWithdrewEventがもう一度発行されます ==>残高が-100eで、ログに2つのMoneyWithdrewEventが含まれる一貫性のない状態です 私が理解しているように、この問題に対処するにはいくつかの戦略があります。 a）集約バージョンIDをイベントストアにイベントとともに配置し、変更時にバージョンの不一致がある場合、何も起こらない b）検証層が何らかの方法で作成する必要があることを意味する、いくつかのロック戦略を使用する 戦略に関する質問： a）この場合、イベントログはもはや真実の源ではありません。どう対処するのですか？また、引き出しを許可することは完全に間違っていましたが、クライアントに戻りましたが、この場合はロックを使用する方が良いですか？ b）ロック==デッドロック、ベストプラクティスに関する洞察はありますか？ 全体として、並行性の処理方法に関する私の理解は正しいですか？ 注：同じ人がこのような短い時間枠で2倍のお金を引き出すことは不可能であることを理解していますが、詳細に迷子にならないように簡単な例を取り上げました

20 concurrency  cqrs  event-sourcing 

Event Sourcingの設計に出会い、RESTクライアントが必要なアプリケーションで使用したいと思います（正確にはRESTfulです）。ただし、RESTは非常にCRUDに似ており、イベントソーシングはタスクベースであるため、これらを接続することはできません。RESTサーバーへの要求に基づいてコマンドの作成をどのように設計できるのか疑問に思いました。この例を考えてみましょう： RESTを使用すると、Fileというリソースに新しい状態を設定できます。1つのリクエストで、新しいファイル名を送信したり、親フォルダーを変更したり、ファイルの所有者を変更したりできます。 イベントソーシングを使用できるようにサーバーを構築する方法。私はこれらの可能性について考えていました： フィールドが変更されたサーバ上で決定し、適切なコマンドを作成する（RenameFileCommand、MoveFileCommand、ChangeOwnerCommand、...）と個別にこれらを派遣。ただし、このセットアップでは、各コマンドが失敗し、他のリソースがトランザクションから除外され、リソースへの「アトミックな」変更から除外されます。 発送のみ一つのコマンド（UpdateFileCommand）およびコマンドハンドラでは、より正確に集計では、変更されたフィールドを決定し、代わりに個々のイベントを送信します（FileRenamedEvent、FileMovedEvent、OwnerChangedEvent、...） これはまったく好きではありません：サーバーへのリクエストでは、ヘッダーで使用するコマンドを指定します。UIはまだタスクベースです（ただし、通信はRESTを介して行われます）。ただし、REST通信のその他の使用（外部アプリなど）では失敗します。1つのリクエストで1つのフィールドのみを変更するようにバインドされているためです。また、UI、REST、およびESベースのバックエンドに非常に大きなカップリングをもたらします。 あなたはどちらを好むでしょうか、これを処理するより良い方法はありますか？ サイドノート：イベントソースのためにJavaとAxon Frameworkで書かれたアプリ。

17 design  rest  event-sourcing 

構成より規約を使用してdddアプリケーションを設計する方法を探しています。 集約「クライアント」に「FillProfile」と定義されたコマンドがあるとします。論理的に「ProfileFilled」イベントを発生させます。 コマンドがイベントよりも多く発生する場合、またはコマンドが何らかのロジックに基づいて異なるイベントを発生する場合がありますか？または、これは常に1対1の関係です（1つのコマンドは常に何も発生させないか、特定のタイプの単一のイベントを発生させます）。 これが事実である場合、コマンドが常に同じイベントを発生させるため、その事実に基づいてコンベンションシステムを構築できるため、これを求めています。「RaiseEvent」が「EventRaised」になることを知っています...

16 domain-driven-design  cqrs  event-sourcing 

protobufの構文3は、すべてのフィールドをオプションにし、キーワードrequiredを削除し、optional以前のproto2構文から削除しました。開発者からのコメントを読むと、前方/後方バイナリ互換性を強化するために行われたようです。 しかし、私にとっては、パッケージ名をバージョン管理するだけで強制できます。たとえばcom.example.messages.v1、クライアントが理解できるデシリアライザーを実装できるようにします。同時に、ソフトウェアエンジニアリングの観点から有用なタイプとして指定されている一部の契約を削除します。たとえば、私が持っている場合 message Location { double latitude = 1; double longitude = 2; } proto3ではLocation、必須フィールドの1つを提供しないことにより、完全に有効な半バックアップを作成できます。 クライアント間でデータを交換するためのスキーマベースのシリアル化形式を作成する場合、これは大きな欠点ではありませんか？すべての必須フィールドに有効な値があることを確認するために、各クライアントに追加の検証コードを移動するのは悪くありませんか？

15 event-programming  event-sourcing  protobuf 

上記の質問はおそらくいくつかの「何??」を発生させることを理解していますが、説明しよう： 私は、いくつかの関連する概念、基本的にはSaga-pattern（http://www.rgoarchitects.com/Files/SOAPatterns/Saga.pdf）とEvent-sourcing（A DDD-concept）に頭を包み込もうとしています。：http : //en.wikipedia.org/wiki/Domain-driven_design） まとめた良い投稿：https : //blog.jonathanoliver.com/cqrs-sagas-with-event-sourcing-part-ii-of-ii/ 私はすぐに質問に近づいていますが、最初にそれについて理解していることを要約しようとする必要があると思います（これは間違っている可能性がありますので、その場合は修正してください）次から始まる質問をする： Sagaパターンは、アクション（エンドユーザー、自動化など、本質的にデータを変更するもの）を指定したブローカーの一種で、そのアクションをビジネスアクティビティに分割し、これらの各アクティビティをメッセージとしてメッセージバスに送信します。次に、それをそれぞれの集約ルートに送信して処理します。 これらの集約ルートは完全に自律的に動作できます（懸念事項の分離、優れたスケーラビリティなど）。 Sagaインスタンス自体には、ビジネスロジックが含まれていません。ビジネスロジックは、アクティビティを送信する集約ルートに含まれています。佐賀に含まれる唯一の「ロジック」は「プロセス」ロジック（多くの場合Statemachineとして実装されます）で、受信したアクション（およびフォローアップイベント）に基づいて何を行うか（つまり、どのアクティビティを送信するか）を決定します Saga-patternsは、一種の分散トランザクションパターンを実装します。つまり、集約ルートの1つ（相互の存在を認識せずに自律的に動作する）の1つが失敗した場合、アクション全体をロールバックする必要があります。 これは、佐賀へのアクティビティレポートの完了時に、すべての集約ルートを持つことで実装されます。（成功とエラーの場合） すべての集約ルートが成功を返す場合、佐賀が次に何をすべきかを決定する（または完了したと判断する）場合、内部ステートマシン 失敗した場合、佐賀は、最後のアクションに参加したすべての集約ルートに対して、いわゆる補償アクション、つまり、各集約ルートが行った最後のアクションを取り消すアクションを発行します。 アクションが「プラス1票」の場合、これは単に「マイナス1票」を実行することですが、ブログポストを以前のバージョンに復元するなど、より複雑になる可能性があります。 イベントソーシング（2つを組み合わせたブログ投稿を参照）は、集約された各ルートが行う各アクティビティの結果を一元化されたイベントストアに保存することを外部化することを目的としています（このコンテキストでは変更は「イベント」と呼ばれます） このイベントストアは「真実の単一バージョン」であり、保存されたイベントを繰り返すだけで（本質的にイベントログのように）すべてのエンティティの状態を再生するために使用できます。 2つを組み合わせること（つまり、集約ルートがイベントソーシングを使用して変更を保存し、佐賀に報告する前に変更を保存する）により、多くの素晴らしい可能性が可能になります。 これを一度に把握するのは大変なので、肩から離す必要があると感じました。このコンテキスト/マインドセットが与えられます（もう一度、間違っている場合は修正してください） 質問：集約ルートが補正アクションを受信し、その集約ルートがイベントソーシングを使用した状態変更を外部委託している場合、すべての状況での補正アクションは、そのイベントストアの最後のイベントの削除だけではありません集約ルートを指定しますか？（persist-implementationが削除を許可すると仮定） それは私にとって非常に理にかなっています（そしてこの組み合わせのもう一つの大きな利点です）が、私が言ったように、これらの概念の誤った/不完全な理解に基づいてこれらの仮定をしているかもしれません。 これが長すぎないことを願っています。 ありがとう。

15 domain-driven-design  cqrs  event-sourcing 

私はCQRSとイベントソーシングの概念を学ぶために、小さなサンプルアプリケーションに取り組んでいます。私が持っているBasket骨材とProduct独立して動作するはず集計を。 実装を示すための擬似コードを次に示します Basket { BasketId; OrderLines; Address; } // basket events BasketCreated { BasketId; } ItemAdded { BasketId; ProductId; Quantity } AddItemSucceeded { BasketId; ProductId; Quantity } AddItemRevoked { BasketId; ProductId; Quantity } ItemRemoved { BasketId; ProductId; Quantity } CheckedOut { BasketId; Address } Product { ProductId; Name; Price; } …

14 domain-driven-design  cqrs  event-sourcing 

奇妙なパターンが検出された場合に電子メールでユーザーに警告する金融アプリケーション用の小さなセキュリティサブシステムを実装すると仮定します。この例では、パターンは図のように3つのトランザクションで構成されます。セキュリティサブシステムは、メインシステムからキューからイベントを読み取ることができます。 私が取得したいのは、パターンの現在の状態をモデル化する中間表現なしで、システムで発生するイベントの直接的な結果であるアラートです。 監視が有効になりました 処理されたトランザクション 処理されたトランザクション 処理されたトランザクション アラートがトリガーされました（id：123） 送信されたアラートの電子メール（ID：123） 処理されたトランザクション これを念頭に置いて、明確な答えのない質問がありますが、イベントソーシングはここで非常にうまく適用できると思いました。この例でトリガーされたアラートには、明らかな副作用があり、電子メールを送信する必要があります。これは、一度しか発生しない状況です。したがって、集合体のすべてのイベントを再生するときに発生することはありません。 ある程度、CQRS /イベントソーシングの文献で何度も見たクエリ側で生成された実体化と同様に送信する必要がある電子メールが表示されますが、それほど微妙な違いはありません。 この文献では、クエリ側は、すべてのイベントを再度読み取る特定の時点で状態の具体化を生成できるイベントハンドラから構築されています。ただし、この場合、前に説明した理由により、そのように正確に実行することはできません。すべての状態が一時的であるという考えはここでそれほど適切ではありません。アラートがどこかに送信されたという事実を記録する必要があります。 私にとって簡単な解決策は、以前にトリガーされたアラートの記録を保持する別のテーブルまたは構造を持つことです。IDがあるため、同じIDのアラートが以前に発行されたかどうかを確認できます。この情報があると、SendAlertCommandはべき等になります。複数のコマンドを発行できますが、副作用は一度しか発生しません。 その解決策を念頭に置いても、これがこの問題のこのアーキテクチャに何か問題があるというヒントかどうかはわかりません。 私のアプローチは正しいですか？ これに関する詳細情報を見つけることができる場所はありますか？ これについての詳細情報を見つけることができなかったことは奇妙です。たぶん私は間違った表現を使っていたのかもしれません。 どうもありがとうございます！

14 event-programming  cqrs  event-sourcing 

サーバーに大量のイベントが流入し、平均して1秒あたり約1000イベント（ピークは〜2000）に対処しなければならない状況があります。 問題 私たちのシステムはHerokuでホストされ、比較的高価なHeroku Postgres DBを使用します。これにより、最大500のDB接続が可能になります。接続プーリングを使用して、サーバーからDBに接続します。 DB接続プールが処理できるよりも速くイベントが入ります 私たちが抱えている問題は、イベントが接続プールが処理できるよりも速く来るということです。1つの接続がサーバーからDBへのネットワークラウンドトリップを終了するまでに、n追加のイベントが入るよりも多く、プールに解放されます。 最終的に、イベントは蓄積され、保存されるのを待機します。プールに使用可能な接続がないため、タイムアウトし、システム全体が動作不能になります。 クライアントから遅いペースで問題のある高周波イベントを発信することで緊急事態を解決しましたが、その高周波イベントを処理する必要がある場合にこのシナリオを処理する方法を知りたいです。 制約 他のクライアントがイベントを同時に読み取りたい場合があります 他のクライアントは、DBにまだ保存されていない場合でも、特定のキーを持つすべてのイベントの読み取りを継続的に要求します。 クライアントはGET api/v1/events?clientId=1、クライアント1によって送信されたすべてのイベントを照会して取得できます。それらのイベントがまだDBに保存されていない場合でもです。 これに対処する方法に関する「教室」の例はありますか？ 可能な解決策 サーバーのイベントをキューに登録します サーバー上のイベントをキューに入れることができます（キューの最大同時実行数は400であるため、接続プールが不足することはありません）。 次の理由により、これは悪い考えです。 使用可能なサーバーメモリを使い果たします。スタックされたエンキューイベントは、大量のRAMを消費します。 サーバーは24時間ごとに1回再起動します。これはHerokuによって課される厳しい制限です。イベントがエンキューされている間にサーバーを再起動すると、エンキューされたイベントが失われます。 サーバーに状態が導入されるため、スケーラビリティが低下します。マルチサーバー設定があり、クライアントがキューに入れられたイベントと保存されたイベントをすべて読みたい場合、キューに入れられたイベントがどのサーバーに存在するかはわかりません。 別のメッセージキューを使用する メッセージキュー（RabbitMQなど）を使用して、メッセージをポンプで送り、もう一方の端にはDB上のイベントの保存のみを処理する別のサーバーがあると仮定します。 メッセージキューがエンキューされたイベント（まだ保存されていない）のクエリを許可するかどうかわからないので、別のクライアントが別のクライアントのメッセージを読みたい場合、DBから保存されたメッセージとキューから保留中のメッセージを取得できますそれらを連結して、読み取り要求クライアントに返送できるようにします。 複数のデータベースを使用し、それぞれが中央のDBコーディネーターサーバーでメッセージの一部を保存して、それらを管理します しかし、もう1つの解決策は、中央の「DBコーディネーター/ロードバランサー」で複数のデータベースを使用することです。イベントを受信すると、このコーディネーターはメッセージを書き込むデータベースの1つを選択します。これにより、複数のHerokuデータベースを使用できるようになり、接続の制限がデータベースの500倍になります。 読み取りクエリで、このコーディネーターはSELECT各データベースにクエリを発行し、すべての結果をマージして、読み取りを要求したクライアントにそれらを送り返すことができます。 次の理由により、これは悪い考えです。 この考えは...ええと..オーバーエンジニアリングのように聞こえますか？同様に管理するのは悪夢です（バックアップなど）。構築と保守は複雑で、絶対に必要でない限り、KISS違反のように聞こえます。 一貫性を犠牲にします。このアイデアを採用すれば、複数のDBでトランザクションを実行することはできません。

13 architecture  performance  scalability  event-sourcing 

そのため、実際のプロジェクトにパターンを適用する機会は一度もありませんでしたが、しばらくの間、イベントソーシングとCQRSをいじっていました。 読み取りと書き込みの懸念を分離することの利点を理解しています。また、イベントソースとは異なり、イベントストアとは異なる「読み取りモデル」データベースに状態の変更を簡単に投影できます。 私があまりはっきりしていないのは、イベントストア自体から集計を再水和する理由です。 「読み取り」データベースへの変更の投影が非常に簡単な場合、スキーマがドメインモデルと完全に一致する「書き込み」データベースへの変更を常に投影しないのはなぜですか。これは、事実上スナップショットデータベースになります。 これは、ES + CQRSアプリケーションでかなり一般的だと思います。 この場合、イベントストアは、スキーマの変更の結果として「書き込み」データベースを再構築するときにのみ役立ちますか？それとも、もっと大きなものが欠けていますか？

13 cqrs  event-sourcing  eventual-consistency  read-model 

私はほぼ2年間ドメインドリブンデザインについて読んでおり、日々の仕事にいくつかの概念を慎重に導入するか、少なくともドメインドリブンデザイン内で定期的に行うことができる方法の計画を立てています。 特に、ドメインオブジェクトは書き込み目的にのみ使用されることを意図しているイベントソーシングとコマンドクエリの責任分離（CQRS）についての詳細を読んで、私が始めた結論の1つです。より明確にするために、私が読んだドキュメントの多くで人々が微妙に示唆していることは、ドメインオブジェクトがドメイン中心の操作/計算、検証を行う責任があること、そして主に永続化への道を提供するためにそこにあることを示唆しているようですリポジトリ実装内で提供されるインフラストラクチャ。状態を公開する責任を排除するため、これによりドメインモデルが大幅に簡素化される可能性があるという事実は気に入っていますが。 ドメインオブジェクトが主に書き込み専用オブジェクトとして使用されることが実際に正しい場合は、誰かに答えられることを望んでいるという疑問が生じます。 セッターを持つオブジェクト、またはオブジェクトの状態を変更するがC＃のプロパティゲッターなどから状態を読み取る外部へのパブリックインターフェイスを提供しないメソッドで単体テストを実行するにはどうすればよいですか？そのオブジェクトをテスト可能にするためだけに状態を公開しても大丈夫ですか？ ドメイン内で行われた計算または操作の結果を、それらを永続化せずにユーザーに表示し、ドメインのコンテキスト外の永続化ストアから結果をプルするにはどうすればよいですか？結果を表示するためだけに状態を公開しても大丈夫ですか？ 唯一のプロパティゲッター（getアクセサー）はドメインでも書き込み可能なものでなければならないという経験則ですか？または、読み取り専用プロパティは読み取り専用であり、実際のドメインモデルで必要な役割を果たさないため、読み取り専用プロパティは避けるべき唯一のものであると言いますか？ 関連資料： TDD、DDD、およびカプセル化

13 domain-driven-design  domain-model  cqrs  event-sourcing 

私はドメイン駆動設計（DDD）を研究していて、用語ドリブンとイベントソーシングという用語に出会いました。私はそれがプロデューサーからコンシューマーへのイベントの発行に関するものであることを知っており、ログを保存するので、私の質問は次のとおりです。 イベントドリブンとイベントソーシングの違いは何ですか？

13 event-sourcing 

私は最近イベントの調達について読んでおり、その背後にあるアイデアが本当に好きですが、次の問題にこだわっています。 コマンド（Webサーバーなど）を受信し、結果としてイベントを生成し、それらを中央ストアに格納するN個の並行プロセスがあるとします。また、ストアからイベントを順番に適用することにより、すべての一時的なアプリケーションの状態が個々のプロセスのメモリで維持されると仮定します。 ここで、次のビジネスルールがあるとしましょう。各個別のユーザーには一意のユーザー名が必要です。 2つのプロセスが同じユーザー名Xのユーザー登録コマンドを受信した場合、両方がXがユーザー名のリストにないことを確認し、ルールは両方のプロセスを検証し、両方とも「ユーザーXの新しいユーザー」イベントをストアに保存します。 現在、ビジネスルールに違反しているため、一貫性のないグローバル状態に入りました（同じユーザー名を持つ2人の異なるユーザーがいます）。 従来のNサーバー<-> 1 RDBMSスタイルのシステムでは、データベースは、このような不整合の防止に役立つ同期の中心点として使用されます。 私の質問は、イベントソースシステムは通常、この問題にどのように対処するのかということです。すべてのコマンドを順番に処理するだけですか（たとえば、ストアに書き込むことができるプロセスの量を1に制限するなど）。

12 distributed-computing  event-sourcing  eventual-consistency 

私は基本的に、CQRSの概念と関連する概念に頭を包み込もうとしています。 CQRSには必ずしもメッセージングとイベントソーシングが組み込まれているわけではありませんが、適切な組み合わせのようです（これらの概念を組み合わせた多くの例/ブログ投稿でわかるように） 何かの状態変更のユースケース（SOに関する質問を更新するなど）が与えられた場合、次のフローが正しいと考えますか（ベストプラクティスとして）。 システムは、いくつかの小さなコマンドに分割される可能性のある集約UpdateQuestionCommandを発行します。質問集約ルートをターゲットとするUpdateQuestion、およびユーザー集約ルートをターゲットとするUpdateUserAction（ポイントをカウントするなど）。これらは、ポイントツーポイントメッセージングを使用して非同期的に送信されます。 集約ルートはそれぞれの処理を実行し、すべてがうまくいけば、QuestionUpdatedイベントとUserActionUpdatedイベントをそれぞれ起動します。これらのイベントには、イベントストアに外部委託された状態が含まれます。 これらのイベントは、ブロードキャスト用のpub / subキューにも置かれます。サブスクライバー（読み取りビューを作成する1つまたは複数のプロジェクターの可能性が高い）は、これらのイベントを無料でサブスクライブできます。 一般的な質問：コマンドはPoint-to-Pointで通信される（つまり、受信者が既知である）のに対して、イベントはブロードキャストされる（つまり、受信者が不明である）ことは本当にベストプラクティスですか？ 上記を仮定すると、ポイントツーポイントではなくpub / subを介してコマンドをブロードキャストすることの利点/欠点は何でしょうか？ 例：佐賀はどの集約ルートが最初に参加するのかわからないため、集約ルートの1つに障害が発生した場合に佐賀が果たす必要がある調停の役割が妨げられるため、佐賀の使用中にコマンドをブロードキャストすることが問題になる可能性があります。 一方、コマンドのブロードキャストが許可されると、利点（柔軟性）が得られます。

12 domain-driven-design  cqrs  event-sourcing 

イベントソーシングと一緒にCQRSパターンを使用して、最初のアプリケーションを実装します。集約ルートの作成を適切に処理する方法について疑問に思っています。誰かがCreateItemコマンドを送信したとしましょう。どのように処理する必要がありますか？イベントItemCreatedを保存​​する場所 新しいアイテムの最初のイベントとして？または、すべてのアイテムを集約し、そのイベントリストがItemCreatedイベントのみで構成される、何らかの種類のItemListエンティティが必要ですか？ Udi Dahan は、集約ルートを作成せず、常に何らかのフェッチメソッドを常に使用することを提案しています。しかし、新しいもので、IDが割り当てられていないものを取得する方法。私は背後にある考え方を理解しており、新しいオブジェクトは、それに応答するイベントがゼロで構成される状態を持つオブジェクトであると考えるのはかなり合理的です。しかし、どのように使用すればよいですか？私のような私のリポジトリに明確な方法を持っていなければならないgetNewItem()か、私の作るget(id)方法を受け入れてOptional<ItemId>代わりに？ 編集：しばらく掘り下げた後、アクターを使用した前述のパターンの非常に興味深い実装を見つけました。作成者は、集計を作成する代わりに、新しく作成されたUUIDを使用して、何らかの種類のリポジトリからそれを取得します。このアプローチの欠点は、一時的な不整合状態を許容することです。またdelete、このようなアプローチでメソッドを実装する方法を疑問に思っています。削除済みイベントを集約のイベントリストに追加するだけですか？

11 domain-driven-design  repository  cqrs  event-sourcing 

私はイベントの調達について読んでいて、持続性について質問があります。 すべてのエンティティを含むDBを引き続き使用できますか？または、アプリケーションが起動されるたびにイベントを再生して、メモリ内の各エンティティの最新バージョンを取得する必要がありますか？（大量のデータの場合のように）大規模なシステムでは無駄のように見えますか？ イベントソーシングのポイントは、必要に応じてイベントを再生してデータストアにデータを入力できることです。（またはデータを分析する）

11 event-sourcing