PD
ну, разница там очень существенная при этом.
Size: a a a
2021 January 27
SP
в какой момент начинают хотеть тысячу функций, деплоить там как то что то куда то, поддерживать, организовывать их как то и т.д.?
ну вот смотри. Делаешь ты e-commernce платформу и там тебе надо блок рекомендаций показывать. Ты делаешь 3 сервиса или 3 лямбды или еще чего и меряешь через A/B эффективность.
SP
ну, разница там очень существенная при этом.
разница только в формализации понятий
SP
шо то распределенные приложения где все дробится по бизнес капабилити шо это
PD
Не, разница почти во всех принимаемых при разработке решениях. От хранилищ и до бизнес-транзакций
SP
ну вот смотри. Делаешь ты e-commernce платформу и там тебе надо блок рекомендаций показывать. Ты делаешь 3 сервиса или 3 лямбды или еще чего и меряешь через A/B эффективность.
при этом для разных стран могут быть разные релаизации тупо из-за каких-то культурных различий
AB
ну вот смотри. Делаешь ты e-commernce платформу и там тебе надо блок рекомендаций показывать. Ты делаешь 3 сервиса или 3 лямбды или еще чего и меряешь через A/B эффективность.
меня так сходу уже пугают “три сервиса на блок рекомендаций”, догадываюсь что этих блоков не один десяток и сервисов уже сотка с лишним
SP
Не, разница почти во всех принимаемых при разработке решениях. От хранилищ и до бизнес-транзакций
ну давай расскажи)
PD
меня так сходу уже пугают “три сервиса на блок рекомендаций”, догадываюсь что этих блоков не один десяток и сервисов уже сотка с лишним
Ага. И разные сервисы вместо одной конфигурации.
AB
Ага. И разные сервисы вместо одной конфигурации.
ест-но
SP
меня так сходу уже пугают “три сервиса на блок рекомендаций”, догадываюсь что этих блоков не один десяток и сервисов уже сотка с лишним
вжух так. да.
Ну вот возьми любой монолит и посчитай количество юзкейсов в коде. Их там явно не 10 штук будет.
Ну вот возьми любой монолит и посчитай количество юзкейсов в коде. Их там явно не 10 штук будет.
PD
ну давай расскажи)
ну, я делал системы во всех трех подходах - и там сильно разное. Разный подход к организации bounded context, разные требования к инфраструктуре и т.п.
SP
Ага. И разные сервисы вместо одной конфигурации.
вполне может быть что у тебя это один код и 3 разных варианта DSL написанных какими-нибудь аналитиками данных и запушенными в гит. А ты просто для удобства оперейшенс используешь общую инфраструктуру. Зачем все пытаться к примитивным подходам упрощать?
SP
ну, я делал системы во всех трех подходах - и там сильно разное. Разный подход к организации bounded context, разные требования к инфраструктуре и т.п.
но должны ли они быть разными?) или просто это твоя интерпритация?
PD
вжух так. да.
Ну вот возьми любой монолит и посчитай количество юзкейсов в коде. Их там явно не 10 штук будет.
Ну вот возьми любой монолит и посчитай количество юзкейсов в коде. Их там явно не 10 штук будет.
А нефиг делать по сервису на usecase. Это антипаттерн
AB
вжух так. да.
Ну вот возьми любой монолит и посчитай количество юзкейсов в коде. Их там явно не 10 штук будет.
Ну вот возьми любой монолит и посчитай количество юзкейсов в коде. Их там явно не 10 штук будет.
не надо так
PD
но должны ли они быть разными?) или просто это твоя интерпритация?
должны, увы. так как разные подходы тянут разные технические и орг.решения.
SP
должны, увы. так как разные подходы тянут разные технические и орг.решения.
окей. давай упростим и пока выкинем serverless. там действительно чуть другие факторы влияют. Но вот soa vs microservices. при том что последнее это soa done right
SP
я понимаю что там есть вижен Уди Дахана с его nservicebus и "SOA не микросервисы" и есть Ньюман со своим виженом. Но по факту то
PD
Ну, тут фигня тоже. Так как и под SOA понимают разное, но обычно системы вокруг шины, а микросервисы - именно про микро (2pizzaweek), а не любые.