Слишком много ненужных событий

Question

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

Я работаю в электронной коммерции и всегда стараюсь донести значимые события до своих агрегатов.как PriceIncreasedEvent, ProductDeactivatedEvent, OutOfStockEvent и т. д.

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

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

Это часто случается с другими типами редакционных данных, такими как название / название чего-либо.Я не хочу создавать событие TitleChanged, я знаю, что это запах кода, для домена не имеет значения, что TitleChanged.Я просто хочу изменить это.

Может быть, аутсорсинг был плохой идеей?Как вы, ребята, справляетесь с такими сценариями?

Answer 1

Что стоит рассмотреть при чтении, это сопоставление контекста из доменного дизайна.

Я согласен с VoiceOfUnreason, что вы можете абсолютно смешать традиционный CRUD с Event Sourcing в системе - и, вероятно, должны.

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

Примером может быть Продукт с вашим PriceIncreasedEvent и т. Д., Но также может существовать другой объект Product, которыйосновывается на CRUD - содержит базовые данные, такие как название продукта и изображения, которые решают эту проблему.Все дело в том, насколько вы заботитесь о отслеживании изменений состояния и важны ли сами изменения (события) для вашего домена.

Обычно я объединял их вместе в службе запросов (в стиле CQRS) ииспользовал UUID для объединения агрегатов с сущностью CRUD.

Надеюсь, это поможет!

Answer 2

Может быть, ивент-аутсорсинг был плохой идеей?

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

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

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

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

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

Хорошие новости: естьнет правила, которое говорит, что вы должны использовать источник событий везде.Вы можете выбрать и выбрать.

(Однако существуют некоторые сложности при попытке использовать одну транзакцию для обновления двух разных баз данных.)