DDDの方法論を勉強してから、私は今、私の会社の実際の製品にこれらのコンセプトを適用し始めました。実際、私は、将来の開発のための適切で維持可能なアーキテクチャを作成することが任されています。 NDD開発におけるDDDのコンセプト
は、我々は以下の技術を利用することにしました：EF4（本当にV2）、ユニティ私が最も啓発されている得られた情報の量は、しかし、私は最高のいくつかの疑問が残っています実践：
質問＃1：のDTO - ベストプラクティス
私は私のドメインオブジェクト（POCOクラス）を持っています。これらのクラスを実装する方法はいくつかあります。
- 従来のアプローチ：公共ゲッター/セッター、検証、&適切なビジネスロジックを含むPOCOクラスを作成します。また、DTOを作成し、マッピング技術を使用してDTOを管理します。
- 従来のDTO：上記のようなPOCOクラスを作成しますが、POCOを転送オブジェクトとして使用します。ビジネスオブジェクトは決してドメインから離れるべきではないということは私の理解です。
- ハイブリッド：著者が自分のPOCOオブジェクトとDTOを作成する面白いblog postを見つけました。彼のドメインオブジェクトの中で、彼はDTOのインスタンスを作成します。 ＃1のようにプロパティを複製しないので、メンテナンスが容易になります。これと同じように：
public abstract class POCOBase<T> : ValidationBase, IPOCO where T : DTOBase, new()
{
public T Data { get; set; }
public POCOBase()
{
Data = new T();
}
public POCOBase(T dto)
{
Data = dto;
}
}
public class SomePOCO : POCOBase { }
public class SomeDTO : DTOBase
{
public String Name { get; set; }
public String Description { get; set; }
public Boolean IsEnabled { get; set; }
}
// EXAMPLES
// POCOBase<SomeDTO> somePOCO = new SomePOCO();
// somePOCO.Data.Name = "blablabla";
// somePOCO.Validate();
// return somePOCO.Data;
質問＃2：何のオブジェクトは、UI /サービスレイヤによって返されるべき？
これはDTOの全体点です。裸の属性だけを含む非常に単純で軽量のオブジェクト。それには検証結果も含まれていません。 DTOをクライアントにシリアル化している場合は、クライアントがInvalidRulesコレクションのような検証結果を必要とすると仮定します。
たとえば、AmazonのAPIを使用しているとします。私は私の個人的な店に本を追加したいと思う。 ISBNを送信せずに本を追加しようとすると、サービスはおそらく検証結果のエラーを含む何らかの応答グループを返すでしょう。
何か不足していますか？私は、DTOにビジネスロジックが含まれてはならないという印象を受けました（少なくともDDDの "純粋主義者"から）。 DTOは転送オブジェクトとして十分な情報を提供していないようです。それともDTOと検証結果をカプセル化する新しいタイプのResponseオブジェクトが必要です。
質問＃3：IoCはどれくらいですか？
「異なるアプリケーション の部分を識別し、同じまま、それらの は別に：
私が黄金のルールに従うべきであると私には明らかに思えます。「私には
これは、依存関係を減らすために。のIoCを適用するという点で理にかなって私のプレゼンテーション、ビジネスロジック、およびデータアクセス層の全ては、IoCコンテナを介して通信する。私のアプリケーション層は、共通のインタフェースと抽象化が含まれています。それはそうです私は疑似テストリポジトリを作成することが大好きです。Unityの設定を変更するだけで、私はTDDを利用できます。
私はこれらの質問を明確にしたいと思います。ありがとう
将来的には、それぞれの質問を別々のStackOverflow質問としてください... –