モデル(製品、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では、製品情報はテーブルのproduct
JSON属性に格納され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で変更された場合、それらに依存するすべてのサービスで(突然)変更を行う必要があります。
解決策3
イベント内の製品のGUIDのみを送信-これは、order_placedの次の構造を意味します。
{
order_id: [guid],
product_id: [guid]
}
サービスBおよびCでは、製品情報がproducts
テーブルに保存されます。まだありますproduct_id
上orders
の複製テーブルが、そこのproducts
A、BとCの間のデータは、BとCには、製品に関する情報がAとは異なる場合があります
製品情報は、サービスBとCが作成されるときにシードされ、A/product
エンドポイントを呼び出す(すべての製品の必要な情報を表示する)か、Aに直接DBアクセスを実行して、所定の必要な製品情報をコピーすることにより、製品に関する情報が変更されるたびに更新されます。サービス。
問題:これにより、BとCがAに依存します(シード時)。製品のスキーマがAで変更される場合、それらに依存するすべてのサービスで変更を行う必要があります(シード時)。
私の理解から、正しいアプローチはソリューション1を使用して、特定のロジックごとにイベント履歴を更新することです(製品カタログが変更されておらず、表示される色を追加したい場合は、履歴を安全に更新して現在の状態を取得できます)製品の欠落とイベント内の欠落データの記入)または指定されたデータの不存在への対応(製品カタログが変更され、表示する色を追加したい場合、その時点で過去の指定された製品かどうかわからない色があるかどうか-前のカタログのすべての製品が黒で、イベントまたはコードを更新することで対応できると想定できます)
updating event history
すべてのイベントを通過し、1つのストリーム(v1)から別のストリーム(v2)にコピーして、一貫したイベントスキーマを維持します。
display image at the point when purchase was made
)、または(の意図を表すことはできませんdisplay current image as it within catalog
)
updating event history
-イベント調達イベント履歴はあなたの真実の源であり、決して変更されるべきではなく、前進するだけです。イベントが変更された場合は、イベントのバージョン管理または同様のソリューションを使用できますが、特定の時点までイベントを再生すると、データの状態はその時点の状態になります。