私が「作業単位」の概念を完全に理解していない可能性があります（おそらく）。基本的に、私はそれをオブジェクト指向環境で使用される一種の広範なトランザクションと見なしています。作業単位を開始し、オブジェクトを操作し、コミットまたはロールバックします。しかし、これはどのようにしてそれらのオブジェクトの背後にあるデータストアの実際のトランザクションに分解されますか？
単一のDBとORM（NHibernateなど）を備えたシステムでは、それは簡単です。トランザクションはORMを介して維持できます。しかし、カスタムドメインモデルが多くの異なるデータソースを覆い隠しているシステムについてはどうでしょうか。そして、それらのデータソースのすべてがリレーショナルデータベースではありませんか？（このあたりのファイルシステムでは多くのことが行われています。）
今のところ、「SQL2005 DB、SQL2000 DB、DB2 DB、およびファイルシステムをすべて同じ「アトミック」なビジネスオペレーションでトランザクションを維持することはできない」という考えに固執しています。したがって、今のところ、コード内でトランザクションを手動で維持するのは、チームの開発者（通常は互いに独立して作業する）の責任です。各DBには適切なトランザクションを含めることができますが、全体としてのビジネスオペレーションは手動でチェックされ、重要なステップごとにバランスが取られます。
ただし、ドメインの複雑さが増し、標準の開発者の交代が進むにつれて、このアプローチはますます困難になり、時間の経過とともにエラーが発生しやすくなります。
このようなドメインにどのように対処するのが最適か、または以前にどのように対処したかについて、アドバイスや例はありますか？この場合の実際の「ドメイン」はまだ初期段階にあり、プロトタイプとして進化し、ある日、異種のレガシーアプリケーションの大規模なエコシステムを拡張および消費/置換します。したがって、再設計とリファクタリングの余地は十分にあります。
参考までに、私が現在目指している設計の10,000フィートのビューは、次のとおりです。中央のメッセージベースのサービスを呼び出す、可能な限り小さなクライアントアプリケーションの大規模なコレクション。このサービスは「ドメインコア」への入り口であり、1つの大きなMVCスタイルのアプリケーションと考えることができます。リクエストはサービスに対して行われ（「アクション」のように）、ハンドラー（「コントローラー」のように）によって取得されます。手続き的なものは何でもそこに行きます。それらは、すべてのビジネスルールを含むモデルと相互作用します。モデルは、リスナー（「サービス」？この部分はまだ設計が曇っており、改善される可能性があります）がリポジトリ（データベースx、データベースy、ファイルシステム、電子メール、外部リソース）と対話することによって取得および処理するイベントを公開します。すべての陽気に依存関係-それに応じて注入されます。
すべての冗長性について申し訳ありません:)しかし、誰かが何かアドバイスがあれば、私はそれを聞いてみたいです。（特に）そのアドバイスが「あなたのデザインが悪いなら、代わりにこれを試してみてください...」であるとしても、ありがとう！