А на отладку, которая усложнится ввиду необходимости поднимать черт пойми что, докер и т.д. А организационные проблемы? А деплой? А тестирование? Сделать прилодение микросервисах — много ума и времени не надо. Поддерживать его — другое дело.

У меня вообще такое чувство, что микросервисты — вроде леваков на западе. Вроде и скребеться в мозгу, что что то не так, но в слух не скажешь: пацаны не поймут. Ведь микросервисы — это стильно, модно, молодежно. Боятся показаться несовремеными.

Отнюдь. Любая лишняя хреновина — зло. Хреновина становится лишней, как только на её поддержку начинает тратиться больше времени, чем на задачу, которую она решает.

Сингулярити вообще то.

Микросервисы не исчезнут, потому что у них есть своя область применения. Но они почти всегда используются где не нужно (мода же) и как следствие — неправильно. Короче, если микросервисное приложение — суть порезанный на части монолит, который скоммутирован через контракты веб-сервисов — оно зло. Если базы микросервисов шарят идшники — зло в квадрате.

На который ирл почти всегда болт кладут. Что логично, так как большинство микросервисов создаются по принципу «мы пилили монолит». А раз оно было монолитом — то у него должны быть общие части. Короче говоря, появление библиотеки типа Common.Utils — практически неизбежно.

Вопросы риторические. Я к тому, что микросервисы не спасают от длинных цепочек наследования, а монолиты не обязывают их писать.

Что мешает не создавать длинные цепочки наследования и заменять его композицией, как советовали ещё в GOF 20 лет назад?

Что мешает в приложении с микросервисной архитектурой создать шаренную библиотеку с публичными классами и создавать всё те же длинные цепочки наследования в самих микросервисах?

Рад, что кто то это написал. Микросервисы почти всегда, в 90% случаев, являются злом. В основном потому, что используются неправильно. Микросервисом можно делать исключительно ту часть приложения, которая работает независимо от остальных, либо которая может быть скоммутированна с остальными через очереди сообщений.

Люди же берут монолит, режут его на части и получают тот же самый монолит, только общающийся сам с собой через http запросы и не имеющий представления о транзакционности. При этом, разработка такого приложения усложняется в разы, потому что часто придётся поднимать несколько сервисов, что бы оно хоть как то заработало, или запускать через докер, который отключит часть отладочных средств. Работать тоже будет не ахти, потому что накладные расходы на коммутацию. А уж деплой и вовсе имеет шансы превратиться в ад.

Используйте веб сервисы только когда это необходимо. Когда без них жить будет нельзя. Только так.

Хорош под копирку писать. Где креатив?

Ты говоришь так, будто это мы неправильно базу выбрали, лол. Обычно приходишь уже на готовое расхлёбывать.

Если бы приложение можно было отключить на ночь — проблемы бы не было.

Подумай, если даже бд нормально выбрать не смогли — будет там нормальный код? На самом деле проблема в твоей схеме, что перегонка данных займет время, много. На это время надо приложение отключить, а у клиента это — табу.

Легко говорить. Поди смени бд, когда в ней гигов этак 50 данных на работающем приложении.

Что касается тулов для организации работа — то связка джира/гит/слака работает отлично.

Что касается инструментов — не лезь в это. Лучше найди архитектора без мании на все новое и тяги к демократии.

На кросатлантике там широкие удобные сидения, на которых можно лечь, вот прямо на подушечку, что для 16-тичасового перелета тупо бесценно.

Удобно — да. Бесценно — аж ни разу. Напротив, очень даже дорого.

Кстати, зачем вообще нужен бизнесс класс? Никогда этого не понимал. Даже когда летал по 16 часов — это казалось экстра тратой.

Ты это дояркам объясни)

Комментом промазал. Вопрос к Сайдбаттому.

Кстати да. Что вы хотите оттуда извлечь? ТП в вакууме может быть абстрактно интересна, но где профит?