25

私はこれを読みました、そしてそれは私に二度考えさせます...：

「作業単位のパターンは避けてください。集約ルートはトランザクション境界を定義する必要があります。」

ドメイン駆動設計を適用するUOWパターンを避ける必要があるのはなぜですか？

4

3 に答える 3

32

（私の投稿の前に、V。Vernonによる「ImplementingDomain-Driven Design」の本のこの章を読むことをお勧めします。これは、集計に近づき、質問に対する長い回答を含めるのに役立ちます。）

適切に設計されたシステムでは、1つのコマンドが一度に1つのアグリゲートを変更し、すべてのアグリゲートには、アグリゲートルートの不変条件によって定義される境界があります。したがって、集計に変更を加えると、不変条件がチェックされ、変更が1つのトランザクションに適用されます（または適用されません）。トランザクションの一貫性です。ここで作業単位を使用する必要がありますか？そうは思わないでください。

しかし、一度に複数の集計を変更する必要がある状況に陥ることがよくあります。トランザクションは大きくなり、システムの一部以上に接触し、結果整合性について説明します。この場合、UoWは優れたヘルパーです。

文脈なしで言及されているので、著者が何を考えていたかを推測するのは難しいですが、彼はトランザクションの一貫性のケースについて話したと思います。分散システムでは、システムに結果整合性を提供するためにUoWなどを使用する必要があります。

于 2013-02-05T08:33:24.387 に答える
6

基本的に、M。Fowlerによると、 UoWは「単なる」スマートな永続化ツールです（ただし、このタスクは複雑になる可能性があります）。したがって、IMHOにはDDDアプローチとの本質的な非互換性はありません。これは、技術的なツールよりも、ドーマンモデリングの「精神」に関するガイドラインを提供します。

文脈がなければ、引用の著者が何を考えていたかを知るのは難しいです。しかし、おそらく彼はこれを書いたのは、UoWを使用する場合、エンティティが自分のライフサイクル（および他のエンティティ）を、通常は永続性とトランザクション動作で管理できるようにすることが難しい場合が多いためです。

実際のところ、AOPを使用するDDDスタイルのアプリケーションでUoWパターンを使用することは可能です。この種のツールを使用すると、エンティティ中心のビジネス対応ドメインモデルでDDDの精神を維持しながら、複雑でありながらビジネスに直交するメカニズムを活用して適切なトランザクションの永続性を実現できます。

通常、Javaの世界では、DDDアプリで次のものを使用できます。

これらは、DDD対応（および大幅に@nnotated;]）のエンティティを提供します。

于 2013-02-04T23:30:06.237 に答える
1

まず、アグリゲートは、コマンドを適用するための一連のロードエンティティを保持するためのオブジェクトです。

  • エンティティは、さまざまな集合体に属することができます。
  • 各コマンドは1つのアグリゲートとのみ通信できます。アグリゲートには、コマンドに必要なすべてのエンティティが含まれている必要があります。
  • 集計はコマンド間で再利用できます。

「作業単位」は基本的にオンザフライの集合体であり、これを行うために集合体をコードで明示的に定義する必要なしに、エンティティのセットに対する単一のトランザクション更新を可能にします。

これには、不変条件を保護するミューテーションメソッドを配置するための明示的なAggregateクラスがないという犠牲が伴います。

上位投票の回答には次のものが含まれます。

しかし、一度に複数の集計を変更する必要がある状況に陥ることがよくあります。トランザクションは大きくなり、システムの一部以上に接触し、結果整合性について説明します。この場合、UoWは優れたヘルパーです。

定義上、集約はトランザクションに必要なもののセットであるため、これは無意味です。「2つの異なるアグリゲートからのエンティティが必要」であることがわかった場合、実際に必要なのは、「必要なエンティティへの参照を保持する追加のアグリゲートを定義する」ことです。

于 2021-02-11T13:21:37.803 に答える