永続性やその他のインフラストラクチャの問題を織り込むことなく、ドメイン層を可能な限り「純粋」に保とうとしています。ただし、ドメイン層で RDBMS またはその他の外部依存関係のサービスを使用する必要がある場合があり、その処理方法がわかりません。
たとえば、私のアプリの各ドメイン オブジェクトは IValidatable インターフェイスを実装しています。このインターフェイスはクライアントによって呼び出され、オブジェクトの永続化を妨げる壊れたルールのリストを取得します。場合によっては、前述の検証ルーチンで、特定のレコードの存在を確認するために DAO クラスを呼び出す必要があります。ORM は使用していません。代わりに、Data Access Object パターンを使用して構築された永続レイヤーを使用します。このデータベース アクセスに関するサービス/ラッパー クラスを作成し、ドメイン オブジェクトと連携させる必要がありますか? このレベルの間接化を追加しても問題ありませんか、それともまだドメイン オブジェクトを汚染していますか?
通常の答えは、ある種のオブジェクトリレーショナルインターフェイスを使用することです。ドメインレイヤーは、ドメインモデルのインターフェースを提供します。内部にリレーショナルデータベースがあり、オブジェクトリレーショナルマッピングを実行するには、それらの間にレイヤーが必要です。あなたは「私たちはORMを使用していません」と言いますが、実際にはあなたはそうです：あなたはドメインレイヤーで直接そのマッピングをしているだけです。
そのマッピングを行う問題は、オブジェクトと関係のインピーダンス不一致の問題として知られています。明示的なORMレイヤーを識別しないことを主張する場合は、はい、DBMSの使用の詳細をカプセル化するクラスを作成する必要があります（もちろん、そうすると、そこにORMクラスが導入されます）。
実際、 ORMレイヤーを回避することは非常に困難です。
私は長い間、永続的なドメイン オブジェクトの永続性に関する知識を隠すことはできないと考えてきました。そうしようとすると、ますます不自然になり、奇妙な副作用が発生します。言い換えれば、永続化の知識をドメイン層に組み込むことは問題ないと思いますが、永続化の正確な手段である必要はありません。DAO インターフェイスを使用する必要があります。
検証チェックによっては、競合状態が発生する可能性があることを付け加えておきます。これが原因で発生する可能性のある制約の例外を処理する準備をする必要があります。