Понимание возможной последовательности, BacklogItem и примера задач от Вона Вернона

Question

Я изо всех сил пытаюсь понять, как реализовать Возможную Последовательность с показанным примером BacklogItems и Задач от Вона Вернона. До сих пор я понял следующее утверждение (учитывая случай, когда он разделяет BacklogItem и Task на отдельные совокупные корни):

BacklogItem может содержать одну или несколько задач. Когда все оставшиеся часы от задач BacklogItem равны 0, состояние BacklogItem должно измениться на "ВЫПОЛНЕНО"

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

Как только доменная служба обновляет количество часов задачи, TaskRemainingHoursUpdated событие должно быть опубликовано на DomainEventPublisher который живет в том же потоке, что и исполняемый код. И вот тут я в недоумении со следующими вопросами:

• Я предполагаю, что должен быть подписчик (тоже живущий в той же ветке, который, я думаю), который должен реагировать на TaskRemainingHoursUpdated События. В какой момент в вашем настольном / веб-приложении вы выполняете эту подписку на шину? На самой инициализации вашего приложения? В коде приложения? Есть ли основания размещать индексы домена в определенном месте?
• Должен ли этот индекс (в том же потоке) вызвать репозиторий BacklogItem и выполнить обновление? (Но это было бы нарушением правила не обновлять два агрегата в одной транзакции, поскольку это происходило бы синхронно, верно?).
• Если вы хотите добиться возможной согласованности для выполнения ранее упомянутого правила, действительно ли мне нужен брокер сообщений, такой как RabbitMQ, даже если BacklogItem и Task находятся в одном и том же ограниченном контексте?
• Если я использую этот брокер сообщений, должен ли я иметь фоновый поток или что-то, что просто использует события из очереди RabbitMQ, а затем отправляет событие для обновления продукта?

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

Answer 1

Итак, для начала, вы должны признать, что если BacklogItem является авторитетом для того, является ли это "Готово", тогда он должен иметь всю информацию, чтобы вычислить это для себя.

Так что где-то внутри BacklogItem находятся данные, которые отслеживают, о каких задачах он знает, и известное состояние этих задач. Другими словами, BacklogItem имеет несвежую копию информации о задаче.

Это "в конечном итоге последовательный" бит; мы пытаемся организовать систему так, чтобы кэшированная копия данных в BacklogItem Граница включает в себя новые изменения в состоянии задачи.

Это, в свою очередь, означает, что нам нужно отправить команду BacklogItem информирование об изменениях в задаче.

С точки зрения элемента backlog нам не важно, откуда взялась команда. Мы могли бы, например, сделать это ручным процессом "После того, как вы завершите задачу, нажмите эту кнопку здесь, чтобы сообщить об элементе отставания".

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

В какой момент в вашем настольном / веб-приложении вы выполняете эту подписку на шину? На самой инициализации вашего приложения?

Это кажется довольно разумным.

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

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

Если вы хотите добиться возможной согласованности для выполнения ранее упомянутого правила, действительно ли мне нужен брокер сообщений, такой как RabbitMQ, даже если BacklogItem и Task находятся в одном и том же ограниченном контексте?

Нет; механика водопровода не имеет никакого значения.