Буду ждать! )))

только опыт, и здравый смысл, в первый раз накосячите - главное на подчинённых больше работ не вешайте и в кранч не вводите отдел разработки ( а то за г будут вас считать), потом научитесь. И кстати некоторым подчинённым бывает видней верное направление. После первого косяка, умейте признать ошибку и свалить в другую контору или свапнуть решение (принять на себя удар того что 10 в 6 баков будем свапать еще раз). Хорошая мина при плохой игре погятна всем, не важно как вы пытаетесь. просто начальству выгодно или плевать. А подчинённые и отдел разработки вас за г* будут считать.

В другую контору после первого косяка это радикальненько )

Моя реплика: архитекторы решений (solution architects) создают проекты, которые без их участия скорее всего не состоялись бы. Это некоторая форма посредничества между заказчиком с довольно невнятной потребностью и разработчиками, которые владеют набором технологий, но не поставят свои деньги за потенциально извлекаемую из них пользу. Без архитектора оно бы не связалось в проект. А сидеть внутри уже инициированного проекта, когда основные архитектурные решения давно приняты ... да, скучновато

Это похоже на усилия BA и Грамотного PM. BA устраняет невнятные требования, а реализация в технологии это от PM. Но если нет BA (ему тупо не дают прав менять процессы), а PM как обычно делает вид что понимает и не управляет (бумаги PM это подтверждение работ, но почему-то они считают бумагу работой) то тут конечно Архитектор как раз выступи в роли что вы описали выше.

Лучше чем тащить того монстра и приделывать ему еще пару рук...

Да не, это как раз для системных инженеров и аналитиков. Соглашусь, базовая штука.

У ВА нет варианта реализации. Он из problem space, а не из solution. Ему сложно конкретизировать потребность. Скорее здесь SA нужен,  но тот примеряет всё ко своей системе и не видит других возможностей. А PM - это немного другая роль, он не про технологии, а более тонкие материи: риски, дефициты и пр.

DDD выше упомянули, по нему есть курс, в апреле бесплатный: https://www.pluralsight.com/courses/domain-driven-design-fundamentals

Вдруг будет полезно

Может где то в другой вселенной, у нас к сожалению считают по другому

А насколько вообще SA может подменить BA и избыточны ли оба на проекте?

ддд это для программистов больше чем для архитекторов

В BABOK Guide номер 3 прослеживается мысль, что SA - это частный случай BA. Аналитики разные бывают, кто-то в бизнес-процессах разбирается, кто-то в business intelligence, а кто-то в ИТ. Этакий Business System Analyst

хорошо было бы, если программисты также считали как и вы. Но вообще от разделения доменной области на сервисы зависят и deployment view, и component diagram, ...

ну стратегические паттерны (bounded context, ubiquitous language) полезны и при проектировании архитектуры

Разные - как роли или как должности? Как роли все-таки они сильно отличаются. А как должности - да, обе роли могут быть в одном человеке.

Ага, еще и контроль задач, и архитектуру, в общем давай все смешаем, и будет еще один "оркестр". Как и из PM тоже его можно сделать, а вообще мы же еще... ну в общем не важно, я к тому - не мешайте котлеты с мухами, даже если очень хочется скинуть с себя работу

При чем тут это? Есть разные роли в проекте, которые могут быть по разному распределены по разным людям.
Главное эти роли не потерять вообще

Да... Ну в общем каждому свое. За сим пусть профи отвечают, согласно, своему опыту. Я же отстраняюсь.