したがって、別のORMに切り替えることは不可能でした（私たちが望んでいたことではありません））。
それは間違っているようです。リポジトリパターンの主な利点は、データアクセスロジックを非表示にし、簡単に交換できることです。
これまでのところ、ビジネスロジックをドメインモデルに入れ、リポジトリを介してORM（どちらを選択した場合でも）で作業するように感じています。ただし、アプリケーションのORM部分にMDAツールを引き続き使用したい場合、ここで作成したモデルは非常に貧弱です（つまり、ビジネスロジックが含まれていません）。同様に、ORMにエンティティフレームワーク（.net）またはNHibernateを使用した場合、それも貧血モデルになります。NHibernateをそのまま使用した場合、ビジネスロジックをどこに置くかわかりません。
貧血ドメインモデルは、マーティンファウラーなど、多くの人にとって悪い習慣と見なされています。このようなモデルは、優れたオブジェクト指向の設計ではなく、手続き型の設計手法につながるため、このような設計は避けてください。次に、データクラスとマネージャー/処理クラスがあり、状態と動作を分離します。しかし、オブジェクトは実際には「状態と動作」でなければなりません。
NHibernateは永続性の無知で素晴らしい仕事をします。XMLまたはFluentNHibernateを使用してマッピングの詳細を非表示にして、単純なPOCOを作成できます。NHibernateを使用してリッチドメインモデルを作成するのは非常に簡単です。エンティティフレームワークとMDAツールでもそれができると思います。このツールが部分クラスを生成する限り、新しい世代がユーザー作成コードを破壊することを心配する必要なく、生成されたコードをかなり簡単に拡張できます。
この長い話を短くするために。NHibernateを使用するとき、何も繰り返さないので、リッチドメインモデルを採用できなくなります。FluentNHibernateで使用し、手動でマッピングすることをお勧めします。マッピングコードの記述には、5〜10分しかかかりません。エンティティフレームワークについても同じことが当てはまり、そのツールは少なくとも簡単に拡張できる部分クラスを作成すると思います。
私はこのように考えるのは正しいですか、つまりDDDではドメイン内のすべてのビジネスロジックを使用し、リポジトリ経由で永続化するためにORMを使用するだけですか？
ほとんどの場合、あなたは正しいです。リッチドメインモデルが必要です。特に、物事がますます複雑になると、適切に設計すると、保守や拡張が容易になります。ただし、DDDは、ビジネスロジックを実装する（ドメインレイヤーとアプリケーションレイヤー）サービス、および作成ロジックをカプセル化するファクトリーも認識していることに注意してください。
また、ビジネスロジックをドメインロジックと実際のアプリケーションビジネスロジックに区別する傾向もあります。ドメインロジックは、ドメインがどのように相互作用して動作するかであり、アプリケーションロジックは完全に異なるレイヤーであり、特定のユースケース/アプリケーションでドメインがどのように使用されるかをカプセル化します。多くの場合、特定のユースケースをサポートし、より強力にするために、ドメインモデルを更新する必要があります。