Muに答えたくなりましたが、詳しく説明したいと思います。要約すると、ORM の選択によってドメイン モデルの定義方法が決まることはありません。
ドメイン モデルの目的は、ドメインをモデル化する豊富なオブジェクト指向 API になることです。真のドメイン駆動設計に従うには、ドメイン モデルをテクノロジに制約されずに定義する必要があります。
言い換えれば、ドメイン モデルが最初に来て、すべてのテクノロジー固有の実装は、その後、ドメイン モデルと問題のテクノロジーの間をマッピングするマッパーによって処理されます。多くの場合、これには両方の方法が含まれます。ORM の選択によって制約が導入される可能性のあるデータ アクセス層と、UI テクノロジが追加の要件を課す UI 層です。
実装がドメイン モデルから著しくかけ離れている場合は、Anti-Corruption Layerについて説明します。
あなたの場合、Anemic Domain Model と呼ばれるものは、実際にはデータ アクセス層です。最良の手段は、テクノロジに中立な方法でエンティティへのアクセスをモデル化するリポジトリを定義することです。
例として、注文エンティティを見てみましょう。テクノロジーに制約されない注文をモデル化すると、次のような結果になる可能性があります。
public class Order
{
// constructors and properties
public decimal CalculateTotal()
{
return (from li in this.LineItems
select li.CalculateTotal()).Sum();
}
}
これは Plain Old CLR Object ( POCO ) であるため、テクノロジによる制約を受けないことに注意してください。問題は、これをどのようにデータ ストアに出し入れするかです。
これは、抽象 IOrderRepository を介して行う必要があります。
public interface IOrderRepository
{
Order SelectSingle(int id);
void Insert(Order order);
void Update(Order order);
void Delete(int id);
// more, specialized methods can go here if need be
}
選択した ORM を使用して IOrderRepository を実装できるようになりました。ただし、一部の ORM (Microsoft の Entity Framework など) では、特定の基本クラスからデータ クラスを派生させる必要があるため、POCO としてのドメイン オブジェクトにはまったく適合しません。そのため、マッピングが必要です。
認識すべき重要なことは、意味的にドメイン エンティティに似た厳密に型指定されたデータ クラスを使用している可能性があるということです。ただし、これは純粋な実装の詳細であるため、混乱しないでください。たとえばEntityObject から派生する Order クラスはドメイン クラスではありません。これは実装の詳細であるため、IOrderRepository を実装するときは、 Order Data Classを Order Doman Classにマップする必要があります。
これは面倒な作業かもしれませんが、AutoMapperを使用して行うことができます。
SelectSingle メソッドの実装は次のようになります。
public Order SelectSinge(int id)
{
var oe = (from o in this.objectContext.Orders
where o.Id == id
select o).First();
return this.mapper.Map<OrderEntity, Order>(oe);
}