純粋主義者 (私は純粋でいようとする) は、モデルがデータを表していると言うでしょう。したがって、永続化する必要があるものはすべて、リポジトリを介して必要な場合にのみ実行されます。また、複雑なエンティティがある場合は、サービスを使用してそれらを結合したいと考えています。たとえば、User + Employee = IUserEmployeeService を介してのみアクセスできる UserEmployee エンティティです。
これらの漠然とした声明で、ここに絶好の機会があります。
腐敗防止レイヤーを構築することで、同時にレガシー DB からの移行を開始できます。
これは、DDD プレイブックの別の章です。腐敗防止レイヤーは、ファサード、トランスレーター、およびアダプターを使用してレガシー システムとインターフェースし、レガシー DB を純粋なドメイン モデルで分離するために使用されます。
さて、これはあなたが望んでいたよりもはるかに多くの作業になるかもしれません. したがって、この時点で自問する必要があります。
このレガシー DB から移行するプロセスを開始しますか? それとも、アプリケーションの存続期間中そのまま残しますか?
移行を開始できるという答えが得られた場合は、実際のドメインを希望どおりにモデル化します。通常のリポジトリとサービスで永続化します。収納したいようにデザインして楽しんでください。次に、集約ルートのサービスを使用して腐敗防止レイヤーに到達し、エンティティを引き出してローカルに保存/更新し、ドメインのエンティティに変換します。
答えが、レガシー DB がプロジェクトの存続期間中残るというものである場合、タスクははるかに簡単になります。ドメインのサービス (UserEmployeeService など) を使用して、腐敗防止の UserFacade および EmployeeFacade に到達します (「リモート サービス」の概念に似ています)。
Facades 内で、アダプタ (LegacyDbSqlDatabase など) を使用してレガシー データベースにアクセスし、生の legacyUser() を取得します。次のステップは、レガシー ユーザー データを User() エンティティの実際のドメイン バージョンに変換する UserTranslator() および EmployeeTranslator() マッパーを使用し、それを UserFacade から UserEmployeeService に戻し、そこで結合されることです。同じ場所から来た Employee エンティティ。
おっと、それはたくさんのタイピングでした...
腐敗防止レイヤーのアダプターとファサードを使用すると、Linq-to-Sql など、やりたいことを何でも実行できます。従来の DB/システムを、独自のバージョンの User() および Employee() エンティティと値オブジェクトを持つ、適切で純粋なドメインから完全に分離しているため、それは問題ではありません。