Active Directoryにいくつかの変更（グループからのユーザーの追加/削除、ユーザーの属性値の変更など）を行うアプリケーションがあります。
現在、それを再設計中です（「スパゲッティコード」からより階層化されたソリューションへ）。Active Directoryの管理機能は、ドメインレイヤーである程度抽象化したいものですが、同時に、ほとんどの機能はテクノロジに大きく依存しています。
すべてのActiveDirectoryアクセスコードをDBアクセスとともにデータアクセス層に配置する必要がありますか、それとも関数のActive Directoryライブラリを作成し、ドメインモデルからこのライブラリを直接呼び出すことは問題ありませんか？それはドメインオブジェクトを永続的に認識させます、そしてそれはおそらく悪い考えですか？
または、すべてのActive Directoryアクセスを代わりにサービス層で実行し、ドメイン層を含まないようにする必要がありますか？
ドメインモデルはテクノロジーに依存しない必要があるため、ADコードをドメインモデルに入れないでください。
本質的に、ADコードはデータアクセスの単なる別の形式であると言えます。したがって、ADコードはデータアクセス層（DAL）に属します。ただし、単一責任原則（SRP-モジュールと個々のタイプに適用されます）に違反するため、データベースモジュールと一緒には属しません。
データベースアクセスとバンドルする代わりに、独自のライブラリに実装します。概念的には同じレイヤーに属しますが、動作が異なるため、同じレイヤーに2つのライブラリがあります。これはまったく問題ありません。各レイヤーに必要な数のライブラリを含めることができます。
ドメインモデルでは、ADアクセス（およびDBアクセス）を抽象化として扱います。抽象リポジトリはデフォルトのアプローチです。ADライブラリにはADリポジトリの実装が含まれ、DBライブラリにはDBリポジトリの実装が含まれます。
これは、ドメイン駆動設計および腐敗防止レイヤーの概念によく適合します。
依存性注入（DI）を使用して、具体的なリポジトリをドメインモデルに接続できます。
テクノロジー固有のものは実装の詳細であり、ドメインモデルに入れるべきではないと思います。