Перерастает в монолит - значит по мере роста выбирает в себя другие доменные области, не разбиваясь дальше на сервисы? Это как раз задача архитектора в MSA. Это решение может быть принято вне команды.
А еще в плане практик вспомнился рассказ на archdays про inner-sourcing - это еще один вариант.

Извините, я еще начинающий:) У меня схема изображающая схему компонентов и их взаимодействие между собой. Верхнеуровневое. Заказчик главным образом, хочет видеть из чего сделана наша программа в т.ч. на схеме ОС и БД

Проблема колодца в том что он тщательно скрывает свои проблемы внутри,
архитектор “снаружи” может увидеть ситацию уже когда будет поздно

тогда да - нарисуйте элементы "бд", "ядро", "очередь", "фронт", "балансер" итп, к ним можно подписать используемую технологию, типа "бд - oracle", "аппсервер - weblogic"

смешанная диаграмма, помесь деплоймента и структурной (или типа того)

*пометил для чтения

главное, чего не надо делать - не надо бояться рисовать "не как положено". Есть необходимость отразить какую-то информацию - отражай.
Картинки это инструмент донесения информации, а не священная корова или стандарт, за нарушение которого лишат премии )

Тогда все таки больше, чем 2 варианта решения. Например, все таки минимальное участие архитектора, на планированиях или в ревью. И это лучше, чем другая команда будет постфактум разгребать. Хотя и может тормозить процесс. Получается trade-off контроль/скорость разработки.

Спасибо:)

1. А как порекомендуете - стоит указывать все эти компоненты в диаграмме?  maven, postgresql, hibernate, jboss, fasterxml, glasfish, javax, pam, ald,  linux oc

Или чтото лишнее?

Примечание. Программа двухзвегка, толстый клиент и база с сервером, сделана на java,

И еще уважаемые коллеги, подскажите пжта, а существует ли сайт на котором архитекторы выкладывают на обозрение свои работы, диаграммы?

сомневаюсь, как бы обычно считается, что это суперсекретная собственность компании, где ты работаешь)

я бы оставил то, что важно. И вещи одного уровня.
То есть, если нужно показать стек заказчику, то postgre, jboss, gf, особняком линукс. Ну кого, простите, волнует, чем там программисты проекты собирают, или какие там либы в проект подтянуты?
Если это рассказ программистам о том, с чем им придётся работать, тогда наоборот, больше упор на конкретику (но тогда и картинка будет совсем другая - вместо "вот бд, вот бэкенд, вот два сервака, где они живут" будет "вот в целом проект, вот структура его, а вот там либы, а собирается оно вот здесь вот так")

сейчас кто-нибудь посоветует читать про architecture levels и уровни абстракции, и в целом правильно, но это громоздкий совет)

Я уже связался. Предложил подход = МПП. По индукции как инженер и по дедукции как Сименон

Ничуть не субъективно, достаточно расспросить их, что они оба два построили и что при этом использовали, чем руководствовались, фундаментальные понимания построения того или иного типа арохитектуры спросить и т.д.

ОК. И какой же критерий проведения разграничительной линии?

например как процесс согласования тех.решений, мы так сейчас делаем

Кто правильнее и интереснее расскажет и покажет, какой же ещё

Кто больше в бизнес процессах погружен ит.д., кто меньше деталям уделяет внимание