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

CQRSではバグを修正するのは簡単で、イベントを再デプロイして再生するだけだと言われています。 ただし、イベントを再生するだけでアイテムが2回出荷される場合、イベントの1つが原因で、制御できない外部システムが顧客に「アイテムを出荷する」原因となる場合はどうでしょうか。 それをどのように解決しますか？

10 distributed-computing  cqrs  event-sourcing 

cqrsアーキテクチャで新しい集約ルートを作成するにはどうすればよいですか？この例では、最初の1つのAR1への参照を保持する新しい集約ルートAR2を作成します。 開始点としてAR1メソッドを使用してAR2を作成しています。これまでのところ、いくつかのオプションが表示されます。 AR1の内部メソッドでは、リポジトリにアクセスできるドメインサービスを使用して、このオブジェクトをcreateAr2RootOpt1呼び出しnew AR2()てdb imediatellyに保存できます。 最初の集約ルートなどでイベントを発行できます。SholdCreateAR2Eventこれに反応してコマンドCreateAR2Commandを発行するステートレスサガがあり、それが処理されて実際にAR2が作成されて放出されAR2CreatedEventます。イベントソースを使用する場合、SholdCreateAR2Event最初の集約ルートの状態には影響しないため、イベントストアに保持されません。（または、これをイベントストアに保存する必要がありますか？） class AR1{ Integer id; DomainService ds; //OPTION 1 void createAr2RootOpt1(){ AR2 ar2 = new AR2(); ds.saveToRepo(ar2); } //OPTION 2 void createAr2RootOpt2(){ publishEvent(new SholdCreateAR2Event()); //we don't need this event. Shoud it still be preserved in event store? } } class AR2{ Integer id; Integer ar1Id; …

10 domain-driven-design  event-programming  cqrs  event-sourcing  entity 

私はDDDの方法と関連する主題を学ぼうとしています。私は、「銀行」を実装するための単純な境界付きコンテキストのアイデアを思いつきました。変更の履歴を保持することも重要です。 アカウントエンティティを特定しました。そのイベントソーシングは、その変更を追跡するのに適しています。他のエンティティまたは値オブジェクトは問題とは無関係であるため、それらについては触れません。 預金と引き出しを検討する場合-変更される集計は1つしかないため、比較的簡単です。 転送する場合は異なります-2つの集計は1つのMoneyTransferredイベントで変更する必要があります。DDDは、1つのトランザクションでの複数の集約の変更を非推奨にします。一方、イベントソースのルールは、エンティティにイベントを適用し、それらに基づいて状態を変更することです。イベントを単純にデータベースに保存できれば問題ありません。ただし、イベントソースエンティティの同時変更を防ぐには、各トランザクションのイベントストリームをバージョン管理するものを実装する必要があります（トランザクションの境界を維持するため）。バージョン管理には別の問題があります-単純な構造を使用してイベントを格納し、それらを読み取って集計に適用することはできません。 私の質問は、「1つの集約1つのトランザクション」、「イベント->集約の変更」、および「同時変更防止」の3つの原則をまとめるにはどうすればよいですか。

10 domain-driven-design  event-sourcing 

CQRS / ESでは、コマンドはクライアントからサーバーに送信され、適切なコマンドハンドラーにルーティングされます。そのコマンドハンドラーは、リポジトリーからアグリゲートをロードし、その上のいくつかのメソッドを呼び出して、それをリポジトリーに保存します。イベントが生成されます。イベントハンドラー/佐賀/プロセスマネージャーは、コマンドを発行するためにこれらのイベントをリッスンできます。 そのため、コマンド（入力）はイベント（出力）を生成し、それがシステムにさらにコマンド（入力）をフィードバックできます。さて、コマンドがイベントを発行せず、別のコマンドをエンキューするのが一般的な方法でしょうか？このようなアプローチは、外部プロセスでの実行を強制するために使用できます。 編集： 私が考えている特定のユースケースは、支払いの詳細の処理です。クライアントはPayInvoiceコマンドを送信します。そのペイロードにはユーザーのクレジットカードの詳細が含まれます。PayInvoiceHandler通過MakeInvoicePayment支払いゲートウェイとの相互作用の原因である別のプロセスにコマンドを。支払いが成功すると、InvoicePaidイベントが生成されます。PayInvoiceコマンドが保持された後、コマンドが保持される前に何らかの理由でシステムがクラッシュした場合MakeInvoicePaymentは、これを手動で追跡できます（支払いは行われません）。MakeInvoicePaymentコマンドが持続した後、システムがクラッシュする前にInvoicePaidイベントが持続する場合、ユーザーのクレジットカードに請求が行われているのに、請求書に支払い済みのフラグが付けられていない可能性があります。その場合、状況を手動で調査し、請求書に手動で支払い済みのマークを付ける必要があります。

10 domain-driven-design  cqrs  event-sourcing  command-message 

私はイベントソーシングについて読んでいて、書き込みが非常にまれであるか、軍事レベルの監査が必要なエキゾチックな状況でのみ意味があるかどうかを自問するのをやめられません。 重要な使用法がある例外的ではないシステムでは、1日あたり数百から数千の書き込みが発生する可能性があり、たとえば、1年間の操作で100万回または2回の書き込み（つまりイベント）に変換されます。現在の状態を取得するためだけに数百万のオブジェクト（イベント）をマージすることは、従来のストレージからのまっすぐな読み取りと比較すると、ばかげた命題のように聞こえます。それでも、イベントソーシングは、最もパフォーマンスの高いシステムの背後にあります（LMAXなど）。 それで、私は何が欠けていますか？イベントストリームからの状態の復元は一般的に行われていますか？または、これを行う必要がほとんどなく、代わりに通常の操作（つまり、CQRSからのクエリストレージを使用）に別のストレージを使用し、例外的な場合（レプリケーション、監査など）にのみイベントから復元するという考えですか？

9 design-patterns  architecture  event-programming  architectural-patterns  event-sourcing 

OOPコミュニティでは、クラスコンストラクターがオブジェクトを部分的または完全に未初期化のままにしてはならないという合意が広まっているようです。 「初期化」とはどういう意味ですか？大まかに言えば、新しく作成されたオブジェクトを、そのクラスのすべての不変条件が保持される状態にするアトミックプロセス。これはオブジェクトに最初に発生するものであり（オブジェクトごとに1回だけ実行する必要があります）、初期化されていないオブジェクトを取得することは許可されません。（したがって、クラスコンストラクターでオブジェクトの初期化を正しく実行するための頻繁なアドバイスです。同じ理由で、Initializeメソッドはしばしばアトミック性を分解し、まだ使用されていないオブジェクトを取得して使用することを可能にするため、眉をひそめられます明確な状態にあります。） 問題： CQRSとイベントソーシング（CQRS + ES）を組み合わせると、オブジェクトのすべての状態変化が順序付けられた一連のイベント（イベントストリーム）でキャッチされ、オブジェクトが実際に完全に初期化された状態にいつ到達するのか疑問に思います。クラスコンストラクターの最後、または最初のイベントがオブジェクトに適用された後？ 注：「集約ルート」という用語の使用は控えています。必要に応じて、「オブジェクト」を読むたびに置き換えてください。 議論の例：各オブジェクトが何らかの不透明なId値（GUIDと考える）によって一意に識別されると仮定します。そのオブジェクトの状態変化を表すイベントストリームは、同じId値によってイベントストアで識別できます（正しいイベントの順序については心配しないでください）。 interface IEventStore { IEnumerable<IEvent> GetEventsOfObject(Id objectId); } さらに、2つのオブジェクトタイプCustomerとがあると仮定しますShoppingCart。焦点を当てましょうShoppingCart：作成されたとき、ショッピングカートは空であり、正確に1人の顧客に関連付けられている必要があります。最後のビットはクラス不変です：にShoppingCart関連付けられていないオブジェクトはCustomer無効な状態です。 従来のOOPでは、コンストラクターでこれをモデル化できます。 partial class ShoppingCart { public Id Id { get; private set; } public Customer Customer { get; private set; } public ShoppingCart(Id id, Customer customer) { this.Id = id; this.Customer = customer; } …

9 cqrs  initialization  constructors  event-sourcing 

イベントソーシング、CQRS、マイクロサービスを使用するシステムを設計しています。これは珍しいパターンではないことを理解しました。このサービスの重要な機能は、記録システムから再水和/復元する機能である必要があります。マイクロサービスは、MQ（Kafka）でコマンドとクエリを生成します。他のマイクロサービスが応答します（イベント）。コマンドとクエリは、監査と復元の目的でS3に保持されます。 現在の思考プロセスは、システムを復元するために、S3からイベントログを抽出し、単純にKafkaにフィードバックできるというものでした。 しかし、これは時間の経過に伴う生産者と消費者の両方の変化を認めることができません。コマンド/クエリレベルでのバージョン管理は、問題の解決にある程度役立つようですが、復元中のコマンドが受信および処理されたときに、まったく同じになるようにコンシューマーのバージョン管理を行うことはできません。 [のバージョン]コマンドを最初に受信したときに処理を実行しているコード。 これを解決するために使用できるパターンはありますか？この機能を宣伝する他のシステムを知っている人はいますか？ 編集：例を追加します。 「バイヤー」が私のオークションサイトの「セラー」に「質問」を送信します。フローは次のようになります。 UI -> Web App: POST /question {:text text :to seller-id :from user-id} Web App -> MQ: SEND {:command send-question :args [text seller-id user-id]} MQ -< Audit: <command + args appended to log in S3> MQ -< Questions service: - Record question in DB …

8 versioning  cqrs  event-sourcing  microservices  apache-kafka 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 6年前休業。 イベントソーシングは、速度、パフォーマンスのスケーラビリティ、透過的な永続性、透過的なライブミラーリングを提供する手段としてLMAXによって普及しました。イベントソーシングと改名される前は、このタイプのアーキテクチャパターンはシステム普及率と呼ばれていましたが、LMAXチームが公開されるまでは、このパターンに慣れていませんでした。 このパターンは多数の本番システムで証明されていますか？したがって、保守的な個人でさえ、このパターンを受け入れる力があると感じる必要がありますか、それともイベントソーシング/システムの普及は、恐れを知らない人のために残されたエキゾチックなパターンですか？

8 java  architecture  performance  management  event-sourcing