2

ドメインモデルのDDDセッターのコンテキストでは、コードの臭いがあります。それらは実際にはドメインの一部ではないという単純な理由で避ける必要があります。ドメインエキスパートが理解できる名詞は含まれておらず、データへの変更は代わりに特定の方法を使用する必要があります。

例：

customer.StreetName = ...
customer.City = ...

そのための正しい方法はcustomer.ChangeAddress、イベントなどを公開できる方法を用意することです。少なくとも私の理解から、これはすべて健全な理論であり、ドメインモデルのセッターが本当に望ましくない理由を完全に理解できます。

しかし、ドメインモデルにセッターがないと、これらのメソッドのテストはかなり難しくなります。

すべての引数を受け取る大きなお尻のコンストラクターがない場合、またはリフレクションマジックを実行しない場合にテストを構築できない場合、Customerインスタンスを取得してテストを実行するにはどうすればよいですか？私はバックエンドでNHibernateを使用しているので、NHibernateは、そもそもこれらのフィールドにデータを入力するために、すでにいくつかのリフレクションマジックを実行しています。

しかし、10個の引数を持つctorがあるのは本当に気分が悪いです..（そして同じことがファクトリメソッドにも当てはまります）。

これについて何かアドバイスはありますか？

ダニエルの挨拶

4

2 に答える 2

3

従来の（非CQRS）DDDでは、すべてのデータを値オブジェクトに因数分解して、エンティティが主要な機能であるIDの維持に還元されるようにすることをお勧めします。

この例では、顧客はAddress ValueObjectを参照し、ChengeAddressメソッドを持っている必要があります。これは次のように単純である必要があります。

public void ChangeAddress(Address address)
{
   //Consistency rules are here
   _address = address;
}

エンティティから値オブジェクトにできるだけ多くのロジックを移動してみてください。良い値のオブジェクトは小さくて不変なので、本質的にテスト可能です。コンストラクターを使用して、特定の状態でVOをインスタンス化し、それを実行します（通常、別の変換されたVOインスタンスを返すメソッドを呼び出すことによって）。

最後になりましたが、私の経験から、ドメインモデルのテストに追加のインフラストラクチャ（リフレクションやその他のツールなど）が必要な場合は、（不要な結合を導入することで）間違っていると言えます。

于 2010-09-16T05:41:21.817 に答える
1

AutoFixtureを試してみることをお勧めします。

少し反射的な愛を混ぜると、ドメインはかなりテスト可能になります：

namespace Unit{
  using System;
  using System.Linq.Expressions;
  public static class ObjectExtensions{
    public static T Set<T,TProp>(this T o,
      Expression<Func<T,TProp>> field,TProp value){

      var fn=((MemberExpression)field.Body).Member.Name;
      o.GetType().GetProperty(fn).SetValue(o,value,null);
      return o;
    }
  }
}

使用法： 

myUberComplexObject.Set(x=>x.PropertyOfIt, newValueOfIt);

そして、少なくともそれらの「大きなお尻」のオブジェクトを小さなオブジェクトに分割するようにしてください。階層を作成してみてください（ユビキタス言語に準拠していることを確認してください）。

于 2010-09-15T14:41:05.180 に答える