SP
внешние штуки которые влияют, пользователи, челы из бэкофиса, внешние системы..
Size: a a a
2021 May 11
k
хттп-адаптер - это почти сага :D
SP
это вообще read операция, при просморе истории заказов стэйт системы не меняется
SP
почти. но нет. вообще нет.
N
совсем уже запутали)
N
и куда отнести тогда ее?
SP
давай еще запутаю. отчет о продажах для сэйлс менеджера кто будет делать? какой элемент системы?
SP
репозиторий заказов?) или репозиторий продуктов? или кто-то третий?
N
в контексте моего вопроса это типо юзер сам свою историю хочет глянуть
N
так кто же?))
SP
ну а сэйлс менеджер хочет посмотреть репорт по продажам его магазина)
SP
суть в целом одинаковая, просто история заказов для пользователя чуть проще звучит
DT
Проекция которая консьюмит ивенты всех систем?
k
в чём ключевое отличие?
Если в адаптере есть транзакция в бд - значит компенсирующее действие будет.
В том, что нет распределённости?
Может даже затрагиваться несколько экторов, но если низкая конкуренция, то вроде ничего страшного 🤔
Если в адаптере есть транзакция в бд - значит компенсирующее действие будет.
В том, что нет распределённости?
Может даже затрагиваться несколько экторов, но если низкая конкуренция, то вроде ничего страшного 🤔
SP
ну давай у нас будет магазинчик попроще)
DT
Хттп адаптер это просто гейтвей в апликейшн слой. Если там и есть логика, то она связана только с особенностями протокола хттп. Все остальное что ты написал - это зона ответственности слоя приложения.
SP
саги - это вполне конкретная штука. описанная в 1987-ом году как реализация распределенных транзакций. То есть некея стэйт машина которая находится в отдельном процессе и которая координирует другие процессы.
k
ну смотри, какие отличительные особенности есть у саги, которая позволяет говорить нам, что это сага, а не репозиторий и не адаптер?
SP
если убрать из саг "распределнные транзакции" получится просто стэйт машина