Если необходима постоянная данных для проверки подлинности в сущности домена или хранимой процедуре базы данных

Question

У меня есть бизнес-правило для проверки на уровне домена для объекта Order. Правило - запрашивающий клиент должен иметь учетную запись в магазине в течение как минимум 30 дней, чтобы получить определенную скидку. Значение 30 может быть определено как константа в объекте заказа уровня домена или как часть хранимой процедуры, где она определяется как константа и возвращается при вызове Службой приложений, а затем передается объекту домена для проверки правильности?

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

Где хранятся эти константы числа для приложений проектирования N-Layer, пытающихся реализовать проект DDD?

Answer 1

Короткий ответ: он принадлежит в домене :)

Ну, интерфейс, определенный в домене таким же образом, что один определяет репозиториев. Реализация может быть где угодно и даже включать в себя реализацию по умолчанию, включенную в домен.

В вашем примере состояние скидки довольно простое. Однако, как насчет сценариев, где определение процентной ставки более сложно? Не хотелось бы, чтобы в хранимой процедуре тестирование было сложнее. Предположим, что один делает, поместите его в хранимую процедуру. Что происходит, когда у вас несколько клиентов, использующих вашу программу, для каждого из которых требуется другое количество дней.

Дело в том, что вам необходимо определить вместе с экспертами вашего домена, как можно настроить и разработать правила, чтобы сделать его максимально гибким. Если, например, вам нужно всего лишь изменить день, тогда вы можете использовать это как некоторые настраиваемые параметры в своей системе.

Однако вы, вероятно, хотите что-то, что следует за шаблоном стратегии. Давай думать об этом, большинство из системы будет шаблон стратегии :)

Во всяком случае, как о следующем (или что-нибудь, что имеет смысл в вашем сценарии):

public interface IDiscountService 
{ 
    float GetDiscount(Customer customer, Order order); 
} 

В реализации Вашего МОГ имеют введенный IDiscountConfiguration, который предоставляет количество дней, где они могут потребоваться для извлечения из (app.config, web-service, xml, database).

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

Кроме того, тестирование различных услуг становится легким, как вы, new до экземпляра вашего устройства проверить и проверить.