CQRS + PHP: где разместить логику при событии

Question

В настоящее время я создаю приложение PHP с идеями CQRS, ES и DDD. Рассмотрим это приложение для опроса с 5 вопросами. Участник может ответить на опрос, ответив на 5 вопросов.

5 вопросов могут быть запрошены со стороны чтения в правильном порядке. Но вопрос может иметь свои условия. Например, не задавайте вопрос 2, когда на ответ B ответ на вопрос 1. С ответом 1B следующий вопрос (ы) задавать: 3, 4 и 5.

Клиент может выполнить команду AnswerQuestion , обработчик обработает эту команду, а событие QuestionAnswered будет запущено. На основе этого события обработчик события обновит сторону чтения, и клиент может запросить следующий вопрос. Когда вопросов нет, спросите, участие будет завершено для участника (и может принять участие в новом участии).

Логика в опросе решит, какие вопросы задать, а какие нет на основе данного ответа, это чистая логика домена. Я боюсь, где разместить/применить эту логику. Также, где будет принято решение о завершении участия. Я думаю, что наиболее вероятный ответ будет: пусть опрос AR определит следующий вопрос, основанный на данных ответах от участия. Или, делитесь логикой в ​​сервисе, пусть читающая сторона запрашивает вопросы и ответы и применяет к ней общую логику.

Помогите мне больше? Заранее спасибо!

Answer 1

Как я понимаю, у вас есть несколько понятий предметной области здесь (простите терминологию, поговорить с экспертом домена уточнить их):

• вопрос (вопрос спрашивают) Отношения (между вопросом)
• обследования (АР, состоит из нескольких вопросов, и содержит отображение
• ) Отношения
• Представлено Обзор

У вас также есть события для ответа на вопросы.

С точки зрения размещения логики я хотел бы сделать следующее:

служба приложений будет эшафот все необходимые детали для уровня представления (предположим, что это будет через вызов Web API).

В службе приложений я бы увлажнил весь запрошенный опрос (выборка из репозитория по имени опроса) и передать его клиенту.

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

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

Когда решить опрос завершен:

Вы можете иметь какое-то состояние на клиенте, который знает, когда это будет сделано (было бы знать, когда был дан ответ все доступные вопросы).

При обработке на сервере вам необходимо подтвердить это, создав объект домена и подтвердив, что опрос завершен, и, если это необходимо, для хранения представленного опроса.

Пару моментов:

Я не вижу, как Event Sourcing или CQRS решает проблему здесь, или это в целях обучения?

Возможно, вы захотите сделать это проще, забыв прочесть модель на данный момент, и просто увлажните Survey из репозитория (как вы это делаете, будь то хранилище событий, ORM или прочитанная модель не имеет значения) прочитанные модели используются для создания представлений, которые нужны клиенту в качестве запросов к потокам событий, означает воспроизведение всех событий (у geteventstore.com есть что-то, называемое проекциями, которые могут строить эти представления «на лету»).

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