бизнес-процесса «Transfer» один-ко-многим ассоциации

Question

Введение в домен

У меня есть коммивояжера. Коммерсант получает BusinessOpportunity. Оба имеют смысл в моем домене быть AR.

Есть два способа модели это:

1. агрегат Salesman не знает о его возможностях для бизнеса, или
2. коммивояжер знает о его списке возможностей (с использованием OpportunityId конечно)

BusinessOpportunity, я считаю, всегда должен знать его SalesmanId.

Вопрос

У меня есть бизнес-процесс, который я планирую на реализации с использованием схемы Process Manager. Это процесс «TransferAllBusinessOpportunities». Это означает, что 1 продавец и «переводит» все свои возможности другому.

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

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

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

Быстрая сводка новостей вопросы:

1. Как бы вы решить эту проблему?
2. Как бы вы могли моделировать домен, чтобы лучше всего справиться с этим?
3. Можно ли использовать прочитанную модель в обработчике команд для выполнения бизнес-процесса?

Еще раз спасибо.

Answer 1

Мета-ответ: вам нужно прочитать, что Грег Янг должен сказать о set validation. Вы будете в лучшем положении, чтобы исследовать свои требования со своими экспертами в домене.

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

Извлечения данных от прочитанной модели должен быть ваш первый курорт. В чем проблема?

Основной контур

1. Query модель чтения для набора
2. Создать команду (ы) для обновления модели записи на основе набора
3. Отправка команды для модели записи
   • модель записи получает требуемые данные из команды (не из модели для чтения)

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

Также: я сказал, что воздаю должное выше, но это может быть не так. Одна вещь, которую вы не описали, - это то, что часть модели «решает» передачу. Может ли модель отклонить команду, чтобы передать эту возможность? При каких обстоятельствах? который содержит состояние, которое определяет, разрешена ли передача?

Возможно, передача не описывается как команда, так как это событие, описывающее решение, принятое каким-то менеджером по продажам.

Я беспокоюсь, что мы должны держать все в записи на стороне модели

Может быть. Существует ли бизнес-инвариант, который нуждается в состоянии набора? Пока это звучит не так, что сильно означает, что набор не принадлежит модели записи. Вы хотите разбить свои агрегаты насколько это возможно, не теряя возможности принудительно применять инвариант.

Можно ли использовать прочитанную модель в обработчике команд для выполнения бизнес-процесса?

«ОК»? Судя по тому, что я читал в разных местах, многие люди так думают. Лично я не убежден.Грубо говоря, вы смотрите на два общих чертах

1. Создать тонкую команду
2. Послать команду в командном обработчик
3. запросов модель чтения для конкретизации недостающих деталей
4. Обработать конкретизирована команда

против

1. Запрос модель чтения
2. Использование результатов запроса для создания команды жира
3. Отправить команду на обработчик команды
4. обработать команду

Я еще увидеть пример, где бизнес будет заботиться о различиях между этими двумя реализациями; последняя реализация легче прогнозировать (вам не нужно ничего знать о состоянии модели чтения, просто состояние агрегата и состояние команды).