В корне агрегата DDD, где должна быть размещена логика проверки существующего агрегата - PullRequest
0 голосов
/ 08 февраля 2019

Предположим, у меня есть Order Совокупный корень, и когда я получаю команду на создание Order, я должен проверить другие ордера по какому-либо условию и отказаться от создания, если эти условия выполнены.Проверка этих условий определенно является бизнес-логикой, но я не должен сначала создавать порядок, пока условия не выполняются.Итак, как реализовать эту проверку, которая соответствует принципам DDD?Это часть службы доменов, службы приложений?

РЕДАКТИРОВАТЬ: есть свойство TableId в Order.Например, мне нужно проверить, занята ли таблица, и, если это так, отказаться от создания заказа.Эта табличная служба может находиться в другом домене приложений, и может потребоваться сетевой вызов.

Я использую источник событий, CQRS, обработчики команд.Извините, я не могу опубликовать код.

1 Ответ

0 голосов
/ 08 февраля 2019

Итак, как реализовать эту проверку, которая соответствует принципам DDD?

«Это зависит».

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

----> create order
<---- here is a list of other information I need
----> the other information
<---- here's the order

Это что-то, что нужно принять экспертам по бизнесу - еслидругие данные устарели на одну секунду, достаточно ли точны вычисления?

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

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

Вот «плохие» новости: механизм, который определяет блокировки в шаблонах проектирования, управляемых доменом, является совокупным.Агрегат - это выражение шаблона крупнозернистый замок ;когда вам нужно заблокировать кучу данных, то бизнес говорит вам, что все эти данные должны быть частью одного и того же агрегата.

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

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

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

Когда достоверные данные находятся где-то еще, забудьте о блокировке.Думайте с точки зрения наилучших усилий, отчетов об исключениях и смягчения конфликтов.

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