Валидация с DDD в SOA-приложении с использованием IoC

На уровне фасада службы у меня есть класс службы с методом/операцией, который принимает объект DTO (контракт на передачу данных). AutoMapper используется для отображения этого DTO в экземпляр моего доменного объекта для применения любых изменений. Запрос передается в мою доменную службу, которая выполняет фактическую работу. Вот как может выглядеть метод:

public EntityContract AddEntity(EntityContract requestContract)
{
    var entity = Mapper.Map<EntityContract, Entity>(requestContract);

    var updatedEntity = Service.AddEntity(entity);

    var responseContract = Mapper.Map<Entity, EntityContract>(updatedEntity);

    return responseContract;
}

Свойства Service и Mapper устанавливаются с помощью инъекции конструктора с Unity в качестве IoC-контейнера.

При выполнении операции доменная служба вносит изменения в сущность, а затем использует хранилище для сохранения изменений следующим образом:

public Entity AddEntity(Entity entity)
{
    // Make changes to entity

    Repository.Add(entity);

    // Prepare return value
}

Хранилище также устанавливается с помощью инъекции конструктора.

Проблема в том, что данные становятся немедленно доступными для других клиентов после их сохранения, поэтому я должен убедиться, что не сохраняются недействительные данные. Я прочитал "синюю книгу" по DDD (Эванс), а также Нильссона и не совсем понимаю, какой подход к валидации мне следует использовать.

Если моя цель - предотвратить переход сущности в недействительное состояние, должен ли я проверять entityContract в своем сервисном методе, чтобы убедиться, что все правила выполнены, прежде чем передавать запрос в доменную службу? Я не решаюсь сделать это, потому что кажется, что я нарушаю инкапсуляцию, определяя эти правила в фасаде сервиса.

Причина, по которой мы используем тонкий фасадный слой, делегирующий полномочия доменным сервисам, заключается в том, что мы раскрываем в нашем API интерфейсы с определенной степенью детализации, но поддерживаем повторное использование посредством композиции тонких доменных сервисов. Учитывая, что несколько фасадных сервисов могут вызывать один и тот же метод доменного сервиса, возможно, лучше делегировать эти правила доменному сервису, чтобы мы знали, что каждое использование проверяется. Или я должен проверять в обоих местах?

Я также мог бы поставить защиту в установщиках свойств, которая предотвращает недопустимые значения от перевода сущности в недопустимое состояние. Это означало бы, что AutoMapper потерпит неудачу при попытке сопоставить недопустимое значение. Однако, это не поможет, когда ни одно значение не отображается.

Я все еще не могу отделаться от мысли, что эти правила являются частью поведения сущности и определение того, является ли объект действительным, должно быть инкапсулировано внутри сущности. Это неправильно?

Итак, сначала мне нужно определить, когда и где я выполняю эти проверки валидности. Затем мне нужно выяснить, как реализовать DI так, чтобы зависимости были развязаны.

Какие предложения вы можете дать?