Управление версиями контента - автоматическое сохранение несовместимо с источником событий

Question

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

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

Answer 1

Должно быть два отдельных ограниченных контекста: Editing bounded context а также Content bounded context (имена могут отличаться, пожалуйста, адаптируйтесь к вашему домену).

в Editing BC ты не должен использовать Event sourcing как механизм сохранения черновиков. Вместо этого вы можете использовать простой CRUD объекты и публиковать события инфраструктуры (т.е. DraftUpdated(id, timestamp)) каждый раз Draft сохраняется (т.е. автосохранение). Затем прослушиватель событий должен переслать это событие подключенным клиентам, чтобы они обновили свою версию черновика. Это событие инфраструктуры не должно сохраняться, это просто временное событие. Вы можете использовать любой доступный транспортный механизм, например SSE или RabbitMQ.