Должен ли я использовать команду для реализации производных доменов в CQRS

Я использую CQRS в приложении для бронирования авиабилетов. один из вариантов использования - помочь покупателю отменить билеты. Но перед фактической отменой заказчик хочет знать штраф.

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

public interface AirTicketService {
     //ticket demand method

     MonetaryAmount penalty(String ticketNumber);

     void cancel(String ticketNumber, MonetaryAmount penalty);
}

У меня вопрос, какая сторона (команда / запрос) отвечает за вызов этой службы домена и возврат результата в приложении в стиле CQRS?

Я хочу использовать команду: CalculatePenlatyCommand. Таким образом, легко повторно использовать модель предметной области, но это немного странно, потому что эта команда не изменяет состояние.

Или мне следует получить читаемую модель билета, если это запрос? Но один и тот же DomainService необходим как на стороне команды, так и на стороне запроса, это тоже странно.

Является ли создание домена запросом?


cqrs event-sourcing axon domain-driven-design
person Yugang Zhou    schedule 23.09.2013    source источник

Ответы (3)


arrow_upward
1
arrow_downward

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

person rmac    schedule 23.09.2013
comment
Для аргумента в Penn () требуется номер ticketNumber, предоставленный нашим провайдером, я сохраняю это значение в агрегате AirReservation и в модели чтения AirReservation. Поэтому перед вызовом службы мне нужно получить модель предметной области из репозитория или запросить readmodel. Но я учту ваше предложение и +1 за ответ и рожок :) - person Yugang Zhou; 23.09.2013
comment
Понятно. В этом случае вы должны получить номер билета из модели чтения, а затем запросить AirTicketService. - person rmac; 23.09.2013

arrow_upward
1
arrow_downward

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

Запросы, которые действительно хорошо подходят этой модели, - это то, что я называю «симуляторами», когда вы хотите запустить симуляцию, используя текущее состояние, например, чтобы дать обратную связь конечному пользователю. Я неоднократно обнаруживал, что логика симуляции может быть повторно используется и как механизм обратной связи, и как механизм управления выполнением (операции / команды записи). Разница заключается в том, что мы делаем с результатом моделирования. Опять же, это сопряжено с риском и требует тщательного суждения.

person Yves Reynhout    schedule 24.09.2013

arrow_upward
1
arrow_downward

Вы можете привести аргументы, что Команда расчета штрафа вовсе не лишняя. Пользователь просит систему что-то сделать - достаточно команды.

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

Или другим способом: на ваше мероприятие, забронированный билет, тоже взимается штраф за отмену бронирования. Затем вы можете сделать это значение доступным в любое время без необходимости его пересчета ... Но это может быть неправильно (?), Потому что штраф во многом будет зависеть от времени, верно (чем позже вы отмените свой билет, тем больше вы заплатите) ?

Если все это требует чрезмерных усложнений и т. Д., То, думаю, я тоже согласен с ответом rmac :)

person turdus-merula    schedule 03.01.2014