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

Question

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

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

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

Answer 1

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

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

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

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

Тем не менее, вы, вероятно, хотите что-то, что следует шаблону стратегии. Если подумать, большая часть системы будет шаблоном стратегии:)

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

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

В реализации вы могли бы иметь IDiscountConfiguration Внедренный, который указывает количество дней, откуда они могут быть получены (app.config, веб-сервис, xml, база данных).

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

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