SP
(не от хорошей жизни)
Size: a a a
2020 August 11
k
ну да, получается, что у составного элемента будет свой стрим событий, а агрегат слушает важные для него и делает проекцию из элементов, важных для принятия решения и сам же кидает свои события связанные с собой (т.е. дубликация событий в связи со сменой контекста)
выглядит странно. Если агрегат слушает события агрегатов, которые внутри него. То есть они событиями обмениваются, но при этом в одной транзакции
SP
выглядит странно. Если агрегат слушает события агрегатов, которые внутри него. То есть они событиями обмениваются, но при этом в одной транзакции
потому обычно они не друг в дружке и существуют на равных и между ними некая "политика". которая говорит что делать если что-то произошло
DT
т.е сага вроде канала между двумя агрегатами
DT
канал управления
SP
сага сама по себе агрегат. Это просто что-то что слушает сообщения и может сама кидать свои сообщения
SP
саги тоже политики, но не все политики саги
DT
тут была мысль к которой пришли - сага - это агрегат, который может слушать чужие события
SP
в целом любой агрегат может слушать любые сообщения)
k
тут была мысль к которой пришли - сага - это агрегат, который может слушать чужие события
это какое-то обрезанное определение, т.к. сага по идее ещё принимает какие-то решения на основании этих событий
SP
это какое-то обрезанное определение, т.к. сага по идее ещё принимает какие-то решения на основании этих событий
любая политика отвечает этому критерию. Саги больше про долгоживущий процесс (то есть есть стэйт и корреляция между несколькими сообщениями)
SP
грубо говоря... политика это условная штука которая слушает сообщение и принимает решение что делать дальше. Сага - это такая политика которая принимает решение на основе стрима событий (то есть больше одного события)
DT
в целом любой агрегат может слушать любые сообщения)
тогда ему придется присвоить это сообщение, иначе он не сможет восстановиться из своего стрима)
SP
тогда ему придется присвоить это сообщение, иначе он не сможет восстановиться из своего стрима)
ты команды сохраняешь в стрим?
SP
скорее всего нет)
DT
нет, но сообщение это же не только команда)
k
любая политика отвечает этому критерию. Саги больше про долгоживущий процесс (то есть есть стэйт и корреляция между несколькими сообщениями)
ещё проблема, что "долгоживущий" тут довольно расплывчатое определение.
В смысле тут же вопрос не времени, а, наверное, количества (> 1) других транзакций, события от которых сага ловит
по моему Уди про это говорил что-то, но я щас не помню 🤔
В смысле тут же вопрос не времени, а, наверное, количества (> 1) других транзакций, события от которых сага ловит
по моему Уди про это говорил что-то, но я щас не помню 🤔
SP
на тему "присваивания" - в event store для этого помимо emit есть linkTo
SP
грубо говоря "вставь в мой стрим ссылку на событие из того стрима"
SP
ещё проблема, что "долгоживущий" тут довольно расплывчатое определение.
В смысле тут же вопрос не времени, а, наверное, количества (> 1) других транзакций, события от которых сага ловит
по моему Уди про это говорил что-то, но я щас не помню 🤔
В смысле тут же вопрос не времени, а, наверное, количества (> 1) других транзакций, события от которых сага ловит
по моему Уди про это говорил что-то, но я щас не помню 🤔
все так, что мол есть как минимум две точки в которых надо принимать решение какое-то, и эти две точки во время коррелируются каким-то стэйтом.