ドメイン駆動設計での作業単位パターンの回避
私はこれを読みました、そしてそれは私に二度考えさせます...：
「作業単位のパターンは避けてください。集約ルートはトランザクションの境界を定義する必要があります。」
ドメイン駆動設計を適用するUOWパターンを避ける必要があるのはなぜですか？
（私の投稿の前に、V。Vernonによる「ImplementingDomain-Driven Design」の本の この章 を読むことをお勧めします。集計に近づき、質問に対する長い回答を含めるのに役立ちます。）
適切に設計されたシステムでは、1つのコマンドで一度に1つのアグリゲートが変更され、すべてのアグリゲートには、アグリゲートルートの不変条件によって定義される境界があります。したがって、集計に変更を加えると、不変条件がチェックされ、1つのトランザクションで変更が適用される（または適用されない）。それはトランザクションの一貫性です。ここで作業単位を使用する必要がありますか？そうは思わないでください。
しかし、一度に複数の集計を変更する必要がある状況に陥ることがよくあります。トランザクションは大きくなり、システムの一部以上に接触し、結果整合性について説明します。この場合、UoWは優れたヘルパーです。
文脈なしで言及されているので、著者が何を考えていたかを推測するのは難しいですが、彼はトランザクションの一貫性のケースについて話したと思います。分散システムでは、システムに結果整合性を提供するためにUoWなどを使用する必要があります。
基本的に、 M。Fowler によると、UoWは「単なる」スマートな永続化ツールです（ただし、このタスクは複雑になる可能性があります）。したがって、IMHOには、DDDアプローチとの本質的な非互換性はありません。これは、技術ツールよりもドーマンモデリングの「精神」に関するガイドラインを提供します。
文脈がなければ、引用の著者が何を考えていたかを知るのは難しいです。しかし、おそらく彼がこれを書いたのは、UoWを使用する場合、エンティティが自分のライフサイクル（および他のエンティティ）を管理できるようにすることが、通常は永続性とトランザクション動作で困難になることが多いためです。
実際のところ、 [〜＃〜] aop [〜＃〜] を使用してDDDスタイルのアプリケーションでUoWパターンを使用することは可能です。この種のツールを使用すると、エンティティ中心のビジネス対応ドメインモデルでDDDの精神を維持しながら、複雑でありながらビジネス直交メカニズムを活用して適切なトランザクションの永続性を実現できます。
通常、Javaの世界では、DDDアプリで次のものを使用できます。
- Hibernate/JPA as a UoW ：ドメインモデルエンティティの「スマート永続性」を提供します（JPAの場合もあります @ Entity's ）
- Spring AOP + AspectJ ：エンティティに [〜＃〜] di [〜＃〜] を提供します
- Spring TX + AspectJ ：エンティティでトランザクションメソッドを有効にします
これらは、DDD対応（および大幅に@nnotated;]）のエンティティを提供します。