Сеттеры в модели домена

В классическом (не-CQRS) DDD рекомендуется вынести все данные в объекты-значения, чтобы ваши сущности были сведены к их основной функции: поддержанию идентичности.

В вашем примере Customer должен ссылаться на Address ValueObject и иметь метод ChengeAddress, который должен быть таким же простым, как:

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

Постарайтесь перенести как можно больше логики из своих сущностей в свои объекты-значения. Они по своей природе более тестируемы, поскольку полезный объект мал и неизменен. Вы используете конструктор для создания экземпляра VO в заданном состоянии и его выполнения (обычно путем вызова метода, который возвращает другой преобразованный экземпляр VO).

И последнее, но не менее важное: исходя из своего опыта, я могу сказать, что если для тестирования вашей модели предметной области требуется дополнительная инфраструктура (например, отражение или любой другой инструмент), вы делаете это неправильно (вводя ненужную связь).

Вы можете попробовать 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);

И Вы должны хотя бы попытаться разделить эти «большие» объекты на более мелкие. Попробуйте создать иерархию (просто убедитесь, что она соответствует повсеместному языку).