Полная Версия: Проверка уникальности сущности в рамках DDD
| Цитата (Santehnick @ 14.02.2018 - 04:24) |
| А у тебя event sourcing + cqrs ? |
Да. Пишу ради эксперимента. В итоге пока что сделал через компенсирующую команду. Команда приводит к пометке дублирующей сущности как инвалидной с указанием причины.
_____________
Профессиональная разработка на заказ
Я на GitHub | второй профиль
| Цитата (Santehnick @ 14.02.2018 - 04:24) |
| В основном мне непонятно, что делать если нужно перепроектировать агрегат значительно отличающийся от текущей версии. Он же после этого не сможет собраться из старых событий. Я читал какую-то недописанную книгу по ES от Грега и там насколько помню предлагалось брать старый поток событий, прогонять его через некий трансформер в новый поток событий или что-то такое. |
Насколько я понял, да, нужно написать "апкастер" (аналог миграций), обработать им ивент стрим и сохранить обработанную копию стрима.
_____________
Профессиональная разработка на заказ
Я на GitHub | второй профиль
| Цитата (Santehnick @ 14.02.2018 - 19:47) | ||
а как гарантируешь, что команда точно выполнится ? |
С точки зрения домена - никак. Команда посылается перед синхронизацией read-модели в случае обнаружения дубликата. Такой вот компромисс.
Впрочем, вероятность коллизии крайне мала ©
_____________
Профессиональная разработка на заказ
Я на GitHub | второй профиль
Позиция Инвиза кажется более логичной (чем она и является.). Сорян, Твин, но ,если упарыватся в ООП, то я за Инвиза
| Цитата (Zzepish @ 14.02.2018 - 20:17) |
| Позиция Инвиза кажется более логичной (чем она и является.) |
Я не заметил, тут что конкурс был? 
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
twin
не, просто мои 5 копеек )мое субъективное мнение )
не, просто мои 5 копеек )мое субъективное мнение )
| Цитата (Santehnick @ 15.02.2018 - 13:43) | ||
Понял, а что будет, если приложение упадет сразу после отправки команды ? Есть какой-то механизм восстановления ? |
Пока не реализовал, ибо вероятность такого сценария для меня приемлема.
Можно приблизительно прикинуть. В слое presentation идет валидация прилетевшей от юзера DTO-шки по read-части. Предположим, что DTO успешно прошла проверку, затем идёт какая-то манипуляция длительностью порядка сотни мс и в конце сохранение стрима. Какая вероятность, что в течение этих 100 мс вклинится другой клиент с дублирующей DTO и успеет сохранить стрим? В принципе, довольно таки низкая, если не сказать, что практически нулевая. Но предположим, что это произошло. При синхронизации read части обнаруживается дубликат и посылается команда. И тут наше приложение падает. Вроде как вероятность внезапного падения по какой-либо причине не такая уж и низкая. Но в нашем случае надо перемножить две вероятности согласно теорверу, насколько я помню. Поэтому получаем, что сценарий довольно таки нереалистичный.
В любом случае, можно и руками потом восстановить, ориентируясь на время регистрации событий.
С теоретической точки зрения решать наверное надо с помощью ProcessManager'а https://medium.com/@drozzy/long-running-pro...rs-c87fbb2ca644
Разница с текущим моим решением по большому счёту только в том, что при синхронизации я буду не команду посылать, а событие.
А ты как думаешь?
_____________
Профессиональная разработка на заказ
Я на GitHub | второй профиль
Еще такая идея пришла: вновь созданный объект по-умолчанию считаем как невалидный (private $valid = false), а команда должна поменять флаг на true.
В таком случае, при отказе системы у нас останется невалидный объект в виде стрима, который можно фильтровать каким-то глобальным фильтром. В перспективе можно почистить event store от мусора.
_____________
Профессиональная разработка на заказ
Я на GitHub | второй профиль
В таком случае, при отказе системы у нас останется невалидный объект в виде стрима, который можно фильтровать каким-то глобальным фильтром. В перспективе можно почистить event store от мусора.
_____________
Профессиональная разработка на заказ
Я на GitHub | второй профиль
Здесь расположена полная версия этой страницы.