Использование агрегатов и событий предметной области с хранилищем nosql

На самом деле я блуждаю по полям DDD и NoSql. Теперь у меня есть сомнения: мне нужно создавать события из агрегата, и я хотел бы использовать хранилище NoSql. Но как я могу быть уверен, что события сохраняются в хранилище, а изменения в корне агрегата не имеют транзакций? Имеет ли это смысл? Есть ли способ сделать это без необходимости использовать источник событий или транзакционную базу данных? На самом деле я искал реализацию двухфазного алгоритма фиксации, но он кажется довольно тяжелым с точки зрения производительности ... Я неправильно подхожу к проблеме? Набитые вопросами... Спасибо за каждое предложение, Энрико.

PS Я новичок в stackoverflow, поэтому любое предложение/критика/... более чем приветствуется Энрико

Изменить 1

Ну, мне нужны события, чтобы уведомлять агрегаты о том, что что-то произошло, и они должны реагировать на изменение. Проблема возникает, когда такие события важны для бизнес-логики. Насколько я понял, после ночи размышлений я не могу использовать хранилище nosql для таких вещей. Позвольте мне объяснить (думая громким голосом :P):

  • С ES (1-й пейзаж): сохраняю "diff" данных. Затем я создаю событие, связанное с ним. 2 операции.
  • С ES (2-й пейзаж): сохраняю "diff" данных. Процесс, наблюдайте за ES и производите событие. Но я привязан к тому, чтобы иметь только один процесс-наблюдатель, чтобы обеспечить правильный порядок событий.
  • С ES (3d декорации): Идемпотентные события. События могут быть выведены по состоянию, и каждое повторное применение события может вызвать изменение у потребителя только один раз, может иметь несколько процессов «удаления из очереди», дубликаты не могут произойти. 1, но накладывает серьезные ограничения на потребителей.
  • В общем: сохраняю данные агрегата. Затем я создаю событие, связанное с ним. 2 операции.

Теперь вопрос становится шире imho, можно ли работать с доменными событиями и nosql, когда такие доменные события являются фундаментальной частью бизнес-процесса? Я думаю, что это может быть лучшим вариантом для реляционной системы... даже если мне потребуется добавить довольно много машин, чтобы получить ту же производительность.

Редактировать 2. Для полноты поиска по запросу "domain events nosql idempotent" в Google: http://svendvanderveken.wordpress.com/2011/08/26/transactional-event.-основанное-nosql-storage/


nosql domain-driven-design aggregateroot domain-events aggregates
person Kendar    schedule 02.04.2013    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Если вам нужен Источник событий, вам следует хранить только события.

Это должна быть последовательность:

  1. совокупный корень получает команду
  2. он запускает правильные события
  3. события сохраняются

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

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

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

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

edit 2 Последнее замечание: если вы выберете ES, подписчик на одно из событий может создать реляционный read-model тоже.

person Giacomo Tesio    schedule 02.04.2013
comment
Да, я думал об этом, потому что с ES я бы создал событие и состояние одновременно, поэтому только одна транзакция. - person Kendar; 02.04.2013
comment
Но без ES я должен сначала сохранить свой агрегат, а затем сохранить событие в очереди событий. Но таким образом у меня должен быть своего рода контекст транзакции, что невозможно безболезненно, например. монгодб. Я не мог быть уверен, что и совокупные модификации, и событие где-то хранятся, и если событие чего-то стоит, я хотел бы быть уверен, что событие сохранено. Пожалуйста, скажите мне, что я не прав!! :) - person Kendar; 02.04.2013
comment
Ты неправ. Вам не нужно сохранять как события, так и состояние объекта. Смотрите мое редактирование для получения дополнительной информации. - person Giacomo Tesio; 02.04.2013
comment
Так что единственный способ - это ES, если я хочу работать с одной операцией... :( - person Kendar; 02.04.2013
comment
Зачем нужны события? Однако, если они вам действительно нужны, да, это должен быть ваш единственный метод сохранения. Однако обратите внимание, что один из подписчиков событий может создать модель чтения в базе данных, если вам это нужно. - person Giacomo Tesio; 02.04.2013
comment
Этот ответ сбивает с толку. Использование доменных событий не означает, что вы должны использовать ES, это две разные вещи. Это не отвечает на исходный вопрос. - person Orestis P.; 30.03.2019