DDD 方法論の研究に数か月を費やした後、私はこれらの概念を自社の実際の製品に適用し始めました。実際、私は将来の開発に適した保守可能なアーキテクチャを作成する任務を負っています。
次のテクノロジーを利用することにしました: EF4 (実際には v2)、Unity
私が得た情報の量は非常に啓発的でしたが、ベスト プラクティスとしていくつかの質問が残されています。
質問 #1: DTO - ベスト プラクティス
ドメイン オブジェクト (POCO クラス) があります。これらのクラスを実装するには、いくつかの方法があります。
- 従来のアプローチ: パブリック ゲッター/セッター、検証、および適切なビジネス ロジックを含む POCO クラスを作成します。また、DTO を作成し、マッピング手法を使用してそれらを管理します。(オートマッパー)
- 従来型 - DTO: 上記のように POCO クラスを作成しますが、POCO を転送オブジェクトとして使用します。ただし、ビジネスオブジェクトがドメインを離れてはならないことは私の理解です。
- ハイブリッド:著者が POCO オブジェクトと DTO を作成している興味深いブログ投稿を偶然見つけました。ドメイン オブジェクト内に DTO のインスタンスを作成します。これにより、＃1のようにプロパティを複製しないため、保守が容易になります。そのようです：
パブリック抽象クラス POCOBase<T> : ValidationBase、IPOCO T : DTOBase、new()
{
パブリック T データ { get; 設定; }
public POCOBase()
{
データ = 新しい T();
}
public POCOBase(T dto)
{
データ = dto;
}
}
public class SomePOCO : POCOBase { }
public class SomeDTO : DTOBase
{
パブリック文字列名 { get; 設定; }
public String 説明 { get; 設定; }
public Boolean IsEnabled { get; 設定; }
}
// 例
// POCOBase<SomeDTO> somePOCO = new SomePOCO();
// somePOCO.Data.Name = "blablabla";
// somePOCO.Validate();
// somePOCO.Data を返します。
質問 2: UI/サービス レイヤーから返されるオブジェクトは何ですか?
これが DTO の要点です。素の属性だけを含む、非常にシンプルで軽量なオブジェクトです。また、検証結果も含まれていません。DTO をシリアル化してクライアントに戻す場合、クライアントが InvalidRules コレクションのような検証結果を必要としていると想定する必要があります。
たとえば、Amazon の API を使用しているとします。個人ストアに本を追加したいと考えています。ISBN を送信せずに本を追加しようとすると、サービスはおそらく検証結果エラーを含む何らかの応答グループを返します。
何か不足していますか？私は、(少なくとも DDD の「純粋主義者」からは) DTO にはビジネス ロジックを含めるべきではないという印象を受けていました。DTO は転送オブジェクトとして十分な情報を提供していないように思えます。それか、DTO と検証結果をカプセル化する新しいタイプの Response オブジェクトが必要です。
質問 #3: どのくらいの IC が多すぎますか?
黄金律に従わなければならないことは明らかです。
「アプリケーションの変化する部分を特定し、同じままの部分から分離します。」
私にとって、これは IoC の適用に関して理にかなっています。依存関係を減らすために、私のプレゼンテーション、ビジネス ロジック、およびデータ アクセス レイヤーはすべて、IoC コンテナーを介して通信します。私のアプリケーション層には、共通のインターフェースと抽象化が含まれています。これ以上 IC を使用するのはやり過ぎのようです。モック テスト リポジトリを作成できる点が気に入っています。また、Unity の構成を変更するだけで、TDD を利用できます。
これらの質問を明確に述べたことを願っています。事前にご協力いただきありがとうございます。