mad_nazgulПравильно пишет.
Но это если кто-то пишет один микросервис.
То да, он и швец, и жнец, и на дуде игрец.

Но если использовать микросервисную архитектуру, то разработка не вполне может свестись к тому что вы привели в первом абзаце.
Кто-то делает микросервисы, а кто-то рисует к ним GUI.

Так что микросервисная архитектура все равно подвержена закону Конвея ;-)
Я-бы проголосовал ЗА микросервисную архитектуру т.к. я в ней вижу возможности
условного разнесения логики на отдельные независимые части (акторы) и выделение
каналов микросервисов - как потоков месседжей между акторами.

Про классической (монолитной) архитектуре когда ПО разрабатывается так что оно
работает либо на кластере (со всеми вытекающими - штормы событий, жесткие
требования по идентичности конфигураций, сложные и неоднозначные механизмы
синхронизации общей памяти, split-brain, и невозможность включать или
исключать узлы на ходу) либо на просто очень мощной и дорогой железке
которая тоже имеет естесвтенные (природные ограничения) по частоте тактового
генератора.

Монолитное ПО обычно обновляется единоразово с остановом сервиса. Оно - критично.
Его нельзя трогать. Над ним трясутся. И сдувают пыль.

Микросервисное ПО (я надеюсь) будет не только синхронным но и асинхронным
что открывает новые возможности по организации процессов обработки данных.

А само по себе ТЗ которое требует единой точки входа и единого "дирижера"
вроде механизма транзакций и требований по ACID нужно просто пересматривать
с точки зрения законов развития естественого мира. Под развитием я подразумеваю
сроки порядка 10-100 лет.

Никто не сможет построить полностью синхронное ПО в условиях коммуникации
нескольких планет солнечной системы. У нас нет физических сред где можно
генерировать такты. Мы сможем строить только потоки данных. Причем односторонние.

Разумеется я не говорю что обычные архитектуры будут не нужны. Они нужны.
Просто их надо пересмотреть с точки зрения ближнего и далекого будущего.

mad_nazgulmaytonпропущено...

Я-бы проголосовал ЗА микросервисную архитектуру т.к. я в ней вижу возможности
условного разнесения логики на отдельные независимые части (акторы) и выделение
каналов микросервисов - как потоков месседжей между акторами.


Я тоже за "микросервисную" архитектуру, т.к. она позволяет собрать сложную систему из не сложных компонентов.
Но проблема в том, что сложность никуда не девается.
Она переходит во взаимодействие м/у компонентами.
Что налагает большую ответственность на разработку API микросервисов.
Верная мысль насчет сложности. Мне пришлось работать как-то в проекте из
50 чел.
Разработка была разбита на команды по 5-7 чел. Работали по Ajile. Времени на освоение
кода почти не было. (знакомая ситуация) Шла разведка боем.
До этого. Я заметил что возникает miss comunications и одна команда не знает чем занята другая.
Разумеется борды с тикетами публиковались но очевидно этого было недостаточно.
Формат митингов не позволял собрать все 50 чел. Кроме того часть людей были в другом
часовом поясе.

Вобщем к чему я это все. Разделение проекта на независимые части и выделение интерфейса
между ними как единого протокола связи - неизбежное явление. Если проект одномодульный
и связи в нем - как спагетти то этот код неизбежно будет утерян к осмыслению. Не будет
на проекте ни одного гуру или знатока который знает все.

И если тренд на микро-сервисность помогает переосмыслить важность и значимость интрефейсов
(один пункт в философии SOLID) то я еще раз голосую +1 за микросервисность.

Кстати в тему сложности на хабре лежит новая статья.
https://habrahabr.ru/post/310782/