0

別のモデルを使用するイベントを検証するオプションは何ですか?

ショッピングカートの例:

ショッピング カートに商品を追加するときに、商品がまだ売り切れていないかどうかを確認する必要があります。

4

2 に答える 2

4

イベントは変更できないものであるため、通常はイベントではなくコマンドを検証します。

質問への回答では、通常、プロセスのビジネス コストがどの程度かによって異なります。たとえば、あなたの例では、売り切れの商品を注文するビジネスのコストはいくらですか? おそらくごくわずかです - アイテムが在庫切れであることを伝える電子メールと、それがどれくらいかかるかの見積もり。

このタイプのシナリオでは、データに対して最終的に一貫性のある読み取りモデルを使用できます。この場合、在庫レベルについて読み取りモデル/キャッシュをクエリしますが、在庫がないものに対して一部の注文が完了する可能性があることを受け入れます。

より厳しい制約がある場合は、理想的には集計を改造するか、注文プロセスでトランザクションやブロックを行うことによって、それらを強制する必要があります。

于 2016-07-30T22:16:40.710 に答える
1

別のモデルを使用するイベントを検証するオプションは何ですか?

Adomain eventは、ビジネスの観点から重要な出来事です。過去に起こったことなので、変えることはできません。OO では、これは一般的にValue Object、つまり、興味深い部分がその属性である不変オブジェクトとして表されます。

一般に、これらDomain EventsAggregate Root(DDD 用語) の操作から得られます。のクライアントはAggregate Root(Application Service別名ユース ケース) です。はオブジェクトをApplication Service受け取り、Commandそれを基に で操作を実行しAggregate Rootます。

検証は、プリミティブ検証、オブジェクト検証、および/または合成オブジェクト検証で構成できます。次に、この検証の実行を担当するオブジェクトは、Aggregate Rootそれ自体および/または検証の特定の目標を持つオブジェクトである必要があります。

ショッピング カートに商品を追加するときに、商品がまだ売り切れていないかどうかを確認する必要があります。

あなたの例に従うと、オブジェクトは次のようになります。

  • コマンド: AddItemToShoppingCartCommand. 追加するアイテムに関する情報と、ショッピング カートの識別子などを保持します。
  • アプリケーション サービス: AddItemToShoppingCartService
  • 集約ルート: ShoppingCartInventory. これが不変条件「...アイテムがまだ売り切れていない場合」を満たすInventoryことを明示するために、意図的に名前に使用しました。Aggregate Root

: 私の意見では、 の在庫をチェックする不変Aggregate Root条件により、Aggregate が大きくなりすぎます。私のアドバイスは、この「売り切れ」が通常発生しない場合は、この不変条件を緩和し、結果整合性を受け入れることです。

于 2016-07-31T12:14:01.903 に答える