Различные инварианты для контекста операции - PullRequest
1 голос
/ 02 марта 2020

Как работать с инвариантами, которые различаются в зависимости от контекста операции? Представьте, что у вас есть микро сервис и инвентарь. Теперь этот резервный функционал зависит от того, кто выполняет операцию. Если это резервирование для исходящей доставки, то могут быть зарезервированы только неразбитые элементы, если это резервирование для внутренних манипуляций, т.е. Shift, тогда резервирование возможно. В настоящее время у нас есть только 1 функция с именем Reserve. Должны ли мы реализовать различные резервные функции? ReserveForOutbound, ReserveForShift? Что произойдет, если появится дополнительное правило? Резервирование для Repack, резервирование для ремонта дефектов?

1 Ответ

0 голосов
/ 02 марта 2020

«Это зависит» от одного:)

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

Первое, что я бы предложил, - это go, чтобы обратиться к экспертам по вашему МСП / домену и посмотреть, как они видят вещи: резервирование для исходящих поставок отличается в их глазах от внутреннего? Они относятся к этим двум под разными именами? Есть ли у них некоторые различия позже в обработке? В этом случае я более склонен полагать, что это случай ошибки во время моделирования и что у вас фактически есть две отдельные сущности вместо операций над одной сущностью. (см. статью Вернона выше). Помните, что единственной обязанностью агрегатов является принудительное применение этих инвариантов, и вы можете создать агрегат только для принудительного применения этого инварианта, если так получится, что эксперты домена согласны. Просто pu sh данные, необходимые для создания агрегата с помощью команды (syn c или из шины сообщений). Скорее всего, если эксперты в области распознают их как отдельные вещи, я бы не удивился, увидев, что есть и последующие различия.

Если дело в том, что здесь действительно есть только одна сущность, я бы лично определенно смоделируйте это как два отдельных метода. Это хорошая ОО практика, а также DDD. Это правило, по-видимому, является значительным отклонением в отношении процесса и ожиданий, и кажется, что наличие двух методов, обусловленных этим бизнес-логикой c (с возможностью совместного использования частного метода), является гораздо лучшим вариантом, чем если-либо и отправленные данные в вашу сущность, чтобы иметь возможность принимать решение, хотя вместо этого это внешняя проблема: это потребитель вашей сущности (человек или система), который запрашивает внутреннее или внешнее резервирование.

Что касается ваших проблем по поводу необходимости нескольких методов, я думаю, что обсуждение с вашим экспертом по домену решит эту проблему.

...