Event-Sourcing: совокупные корни и производительность

Question

Я создаю клон StackOverflow, используя event-sourcing. MVP проста:

1. Пользователи могут создавать вопрос
2. Пользователи могут ответить на вопрос
3. Пользователи могут upvote и downvote ответы на незамкнутых вопросы

Я моделировал вопрос как совокупный корень. Вопрос может иметь ноль или более ответов, и ответ может иметь ноль или более приоритетов и downvotes.

Это приводит к серьезной проблеме с производительностью. Чтобы ответить на вопрос, должен быть загружен вопрос (являющийся совокупным корнем), который требует загрузки всех его ответов. В DDD, не связанный с событиями, я бы использовал ленивую загрузку для решения этой проблемы. Но ленивая загрузка в event-sourcing нетривиальна (http://docs.geteventstore.com/introduction/event-sourcing-basics/)

Правильно ли моделировать вопрос как совокупный корень?

Answer 1

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

Вы, вероятно, хотите, чтобы думать о таких вещах, как показано ниже:

1. Сколько ответов на вопрос, который вы ожидаете.
2. Что произойдет, если кто-то отправил ответ во время вашего ответа. То же самое касается продолжений.
3. Совершает ли upvote просто +1, и вам все равно, или вы можете найти все варианты для пользователя и, например, изменить их на downvote (upvotes определены).

Возможно, вы захотите перейти на отдельные агрегаты, а не из-за проблем с производительностью, а из-за проблем с параллелизмом (вопрос 2).

В соответствии с производительностью и тем, как вы себя чувствуете, вы можете подумать о моделировании его как объекта ценности. (Вопрос 3)

Идите вперед и read ithttp://dddcommunity.org/library/vernon_2011/

Правда производительности хит можно достичь с помощью CQRS чтения/записи разделения http://udidahan.com/2009/12/09/clarified-cqrs/

Answer 2

С простой модели чтения она не должна быть проблемой. Какое максимальное количество ответов вы ожидаете от вопроса? Может быть, несколько сотен, что не имеет большого отношения к денормализованной модели данных.

Событие upvote будет инициировано очень простой командой с несколькими свойствами.

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