mad_nazgulПо идее сервисы для всех услуг есть. Но использовать их в композиции напрямую нельзя, т.к. важно состояние.
Поначалу был "футбол", потом когда разобрались, пришлось потеть всем и back-end`у и front-end`у.

Ещё раз- ответственный за фичу. Он решает, он отвечает. Но исполнитель должен иметь возможность объяснить проблему (качество кадров).

mad_nazgulИ да, теперь я с опаской отношусь к асинхронному взаимодействию.
Т.к. он усложняет задачу как минимум в два раза.

Асинхронное взаимодействие и микросервисы- вещи перпендикулярные.
Много мучаюсь с асинхронными вызовами в монолитной команде и при этом отлично использую синхронные rest-вызовы между микросервисами.

SergunkaА что подразумевает уважаемая публика когда говорят микросервис?
...
В сложном варианте я подогнал три сервиса - БД, Очередь и Редис для кеш манеджера не забыл

Не то.
Вот есть некий сайт. На нём есть ОСНОВНАЯ ФУНКЦИОНАЛЬНОСТЬ.
Тут решают- давайте запилим некую фичу Х, для неё надо добавить тут поле ввода, тут копочки, тут вывести результаты. И сложная логика расчёта этих результатов. И делать это будут люди в другой стране.
Как результат- да, в исходном коде сайта добавляются UI-элементы, которые будут взаимодействовать с новым сервисом Y. UI поправили быстро, а мы теперь делаем этот Y, который стоит на отдельном сервере, дежит нужные данные в свой БД (вообще другой), общается с существующиеми сервисамы по rest-api и сам его же предоставляет.
Т.е. мы получили полную свободу разработки- свой git, свои технологии, своё хранилще артефактов, свой механиз деплоя и т.п. Просто потому, что мы это лучше знаем чем то, что используется в основном приложении.
И при этом наш сервис я уже примерно знаю как и где будет разделён на 3 (минимум) сервиса со своей функциональностью (в первую очередь исходя из рисков падения и последствий этого падения).
А слои это другое. Вообще никак.