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

以前にカフカに出会ったことはありますが、最近、カフカがCQRS、イベントストア（のベース）として使用されている可能性があることに最近気付きました。 Kafkaがサポートする主なポイントの1つ： イベントのキャプチャ/保存、もちろんすべてのHA。 パブ/サブアーキテクチャ 新しいサブスクライバーが事後にシステムに登録できるようにするイベントログを再生する機能。 確かに私はCQRS /イベントソーシングに100％精通しているわけではありませんが、これはイベントストアのあるべき姿にかなり近いようです。面白いことに、イベントストアとして使用されているKafkaについてはそれほど多くの情報を見つけることができません。 それで、それが良いイベントストアになるためにカフカから欠けているものは何ですか？それはうまくいくでしょうか？それを使って生産？洞察、リンクなどに興味がある 基本的にシステムの状態は、通常行われているシステムの現在の状態/スナップショットを保存するだけでなく、システムが受信したトランザクション/イベントに基づいて保存されます。（会計の総勘定元帳と考えてください：すべてのトランザクションは最終的に最終状態になります）これにより、あらゆる種類のすばらしいことが可能になりますが、提供されているリンクを読むだけです。

219 cqrs  event-sourcing  apache-kafka  dddd 

RDBMS（SQL Serverなど）を使用してイベントソースデータを格納している場合、スキーマはどのようになるでしょうか？ 抽象的な意味で話されているいくつかのバリエーションを見ましたが、具体的なものはありません。 たとえば、「製品」エンティティがあり、その製品への変更は、価格、コスト、説明の形式で発生するとします。私がするかどうかについて私は混乱しています： 製品のすべてのフィールドを含む「ProductEvent」テーブルを作成します。各変更は、そのテーブルの新しいレコードを意味し、必要に応じて「誰、何、どこ、なぜ、いつ、どのように」（WWWWWH）を意味します。コスト、価格、または説明が変更されると、製品を表すまったく新しい行が追加されます。 製品のコスト、価格、および説明を、外部キー関係を使用してProductテーブルに結合された個別のテーブルに格納します。これらのプロパティに変更が発生した場合は、必要に応じてWWWWWHを使用して新しい行を書き込みます。 WWWWWHに加えて、イベントを表すシリアル化されたオブジェクトを「ProductEvent」テーブルに格納します。つまり、特定の製品のアプリケーション状態を再構築するために、イベント自体をアプリケーションコードでロード、シリアル化解除、および再生する必要があります。 。 特に上記のオプション2について心配しています。極端に言うと、製品テーブルはプロパティごとにほぼ1テーブルであり、特定の製品のアプリケーション状態をロードするには、各製品のイベントテーブルからその製品のすべてのイベントをロードする必要があります。このテーブル爆発は私に悪臭を放ちます。 「依存している」と私は確信しており、単一の「正解」はありませんが、何が受け入れ可能で何がまったく受け入れられないかを感じ取ろうとしています。また、NoSQLがここで役立つことも知っています。集約ルートに対してイベントを格納できます。つまり、オブジェクトを再構築するためのイベントを取得するためのデータベースへの単一の要求のみですが、ここではNoSQL dbを使用していません。瞬間なので、私は代替案を探しています。

119 cqrs  event-sourcing 

モデル（製品、ID、タイトル、価格）を制御するサービスA（CMS）と、与えられたモデルをどのように表示する必要があるかを示す必要があるサービスB（配送）とC（メール）があるとします。イベントソーシングアプローチでこれらのサービス全体で特定のモデル情報を同期するには 商品カタログがめったに変更されない（ただし変更される）と、出荷および電子メールのデータに頻繁にアクセスできる管理者がいるとします（機能例：B：display titles of products the order containedおよびC：）display content of email about shipping that is going to be sent。各サービスには独自のDBがあります。 解決策1 イベント内の製品に関する必要なすべての情報を送信します-これは以下の構造を意味しますorder_placed： { order_id: [guid], product: { id: [guid], title: 'Foo', price: 1000 } } サービスBおよびCでは、製品情報はテーブルのproductJSON属性に格納されordersます そのため、必要な情報を表示するために、イベントから取得されたデータのみが使用されます 問題：BとCで提示する必要のある他の情報によっては、イベントのデータ量が増える可能性があります。BとCはProductについて同じ情報を必要としない場合がありますが、イベントには両方を含める必要があります（イベントを2つに分割しない限り）。特定のデータが特定のイベント内に存在しない場合、コードはそれを使用できません- 特定の製品に色オプションを追加すると、BおよびCの既存の注文に対して、イベントを更新して再実行しない限り、特定の製品は無色になります。 。 解決策2 イベント内の製品のガイドのみを送信-これは以下の構造を意味しますorder_placed： { order_id: [guid], product_id: [guid] } サービスBおよびCでは、製品情報はテーブルのproduct_id属性に格納されますorders 製品情報は、A/product/[guid]エンドポイントへのAPI呼び出しを実行することにより、必要に応じてサービスBおよびCによって取得されます 問題：これにより、BとCが（常に）Aに依存します。製品のスキーマがAで変更された場合、それらに依存するすべてのサービスで（突然）変更を行う必要があります。 …

10 microservices  event-sourcing