SP
aggregatestore
стор агрегатов тогда
Возможно.
Не спец.
Могу ошибаться в определениях.
Size: a a a
2021 March 13
SP
ну тут вопрос не в определениях а просто в том как переводишь
SP
Вопрос.
Тема: EventSourcing.
Может ли агрегат отвечать за свое сохранение? Принимать event store и вызывать методы сохранения самостоятельно?
В свою очередь Для вызова сохранения агрегата отвечает агрегат стора.
Тема: EventSourcing.
Может ли агрегат отвечать за свое сохранение? Принимать event store и вызывать методы сохранения самостоятельно?
В свою очередь Для вызова сохранения агрегата отвечает агрегат стора.
может но не стоит. Если есть возможность получить стрим на вход и пачку ивентов на выход которые будет уже другая штука персистить будет лучше.
SP
что бы твои агрегаты так и оставались вариантом редьюса стриима
AN
Что то подобное получается
SP
ну похоже на правду. загрузили агрегат, поменяли, сохранили.
SP
или "забрали из стора текущий стэйт агрегата, поменяли, положили новый стэйт в стор". Просто в твоем случае новый стэйт это новая пачка ивентов
AN
Просто меня смущает, что сам aggregate береться за сохранение
https://blog.sapiensworks.com/post/2012/04/18/DDD-Aggregates-And-Aggregates-Root-Explained.aspx
https://blog.sapiensworks.com/post/2014/06/04/Unit-Of-Work-is-the-new-Singleton.aspx
https://blog.sapiensworks.com/post/2012/04/18/DDD-Aggregates-And-Aggregates-Root-Explained.aspx
https://blog.sapiensworks.com/post/2014/06/04/Unit-Of-Work-is-the-new-Singleton.aspx
SP
Просто меня смущает, что сам aggregate береться за сохранение
https://blog.sapiensworks.com/post/2012/04/18/DDD-Aggregates-And-Aggregates-Root-Explained.aspx
https://blog.sapiensworks.com/post/2014/06/04/Unit-Of-Work-is-the-new-Singleton.aspx
https://blog.sapiensworks.com/post/2012/04/18/DDD-Aggregates-And-Aggregates-Root-Explained.aspx
https://blog.sapiensworks.com/post/2014/06/04/Unit-Of-Work-is-the-new-Singleton.aspx
ты видимо неправильно прочитал или перевел
SP
он не "берется за сохранение", он только гарантирует тебе что стэйт останется корректным. За персистенс (именно сохранение в базу) отвечает твой стор агрегатов
SP
или ты о том что месте что мол "стор может разложить твой агрегат на разные таблички"? Ну в любом случае ты что-то не так прочитал
AN
Да.
Вроде бы дошло.
Агрегат стор же организует все действия для сохраняемости.
Вроде бы дошло.
Агрегат стор же организует все действия для сохраняемости.
SP
p.s. вообще агрегаты должны быть маленькими ровно по той причине что это партиции данных и работа с оными происходит последовательно. Два чела одновременно трогают агрегат - у одного конфликт. Больше агрегаты - выше шансы того что два человека потрогают. Но это все к логике приложения сильно привязано. Может быть так что у тебя огромные агрегаты которые всегда только один человек трогает и так последовательно
RL
p.s. вообще агрегаты должны быть маленькими ровно по той причине что это партиции данных и работа с оными происходит последовательно. Два чела одновременно трогают агрегат - у одного конфликт. Больше агрегаты - выше шансы того что два человека потрогают. Но это все к логике приложения сильно привязано. Может быть так что у тебя огромные агрегаты которые всегда только один человек трогает и так последовательно
«Должны» как should?:)
AN
Кмех...
да уж сложновато дается пока что...
Что почитать на тему ES?
да уж сложновато дается пока что...
Что почитать на тему ES?
SP
«Должны» как should?:)
ну не must точно. Опять же меньше агрегаты - больше будешь полагаться на eventual consistency. загоняться на все это имеет смысл только если у тебя collaborative domain.
SP
хм... вообще event sourcing не имеет смысла вне collaborative domain....