0

ORM が作業単位を使用して複数のリポジトリを 1 つのステップでコミットするのを見てきました。

また、DDD と、リポジトリを介して保存された集約ルートの使用も見てきました。イベント ストアの永続性を使用すると、概念的に理解することが非常に明確になります。

私は常にデータ アクセス コードを記述する必要があり、ORM には精通していますが、ドメイン駆動設計とイベント ソーシングは初めてです。イベント ソーシングは優れていますが、多くのインフラストラクチャが付属しています。

最終的には、どの時点 (コード サイズ、データベース エンティティの数) で DDD+ES が CRUD システムよりも余分な労力を費やす価値があるかを判断するのに役立ついくつかのルールが必要です。

私の質問を決定するのに役立つのは次のとおりです。

  1. 単一の作業単位に結合された集約ルートを見たことがありませんが、これは回避できますか? もしそうなら、これはどのような問題を引き起こす可能性がありますか?

  2. DDD では、顧客エンティティに住所と電話番号が埋め込まれている場合があります (値オブジェクト)。一方、ORM では、顧客、電話番号、および住所リポジトリを使用した作業単位があります。これらの異なるアプローチを説明し、理解するための最良の方法は何ですか?

  3. ORM は複数の異なる作業単位 (それぞれが関連および関連するリポジトリ/テーブルを参照する) を使用して集約ルートを表すことができますか?

  4. ドメインから ORM へのインピーダンスの不一致で注意すべき問題/警告の兆候は何ですか? その時点で、イベント ストアへの切り替えを検討できますか?

4

1 に答える 1

2

  1. 集約は一貫性の境界を定義します。NoSQL データベースでは、通常、トランザクションごとに複数のエンティティをコミットすることはできません。したがって、NoSQL を使用した DDD では、作業単位に 1 つの集計のみを含めることが望ましい一方で、現在の集計の外部にあるエンティティへの更新は結果的に整合性のある方法で配信されます。

  2. アドレスと電話が値オブジェクトである場合、リポジトリを持たないでください。ORM では、それらは個別のマッピングではなく、親エンティティのコンポーネントとしてマッピングされます。

  3. この方法で何を達成できるかわかりませんか？

  4. イベント ソーシングに自然につながる問題点の 1 つは、すべての状態変更を集約して保持する必要があることです。さらに、一般的なイベント ソーシングとドメイン イベントの概念は、状態ではなく動作に焦点を当てた別のドメイン モデリング方法論を提供します。すべての状態変更を保持することに潜在的なビジネス価値がある場合は、ES を検討します。インフラストラクチャへの初期投資を行う意思がある場合、ES は ORM の狂気を回避することで、多くの点で単純化できます。CRUD は、イベント タイプが 4 つだけ、または 2 つ (読み取り、更新) のイベント ソーシングと考えてください。最も基本的なドメインを超えて、ES につながるデータへの変更を超えたより多くのコンテキストを持つことが望ましいです。

于 2013-07-01T14:52:07.630 に答える