Умеет человек быть на гребне волны. Думаю, что эта репа будет пользоваться популярностью (сегодня там смотреть пока что нечего, но подписаться стоит):
https://github.com/ddd-crew/ai-ddd-prompts-and-rules

В последнее время начал смотреть старые кинофильмы. Сейчас хорошее кино снимают не так часто, как раньше.

Смотрю фильм "Идти тихо, идти глубоко" ("Run silent, run deep"), 1958г.

На 45 минуте разгорается конфликт по причинам, хорошо знакомым каждому архитектору.

Капитан подводной лодки освоил новый тактический прием ведения боя (лобовую атаку), опробовал его в несложном бою, и уверен, что обладает превосходством, которое может изменить расстановку сил в проливе Bongo, где действует японский эсминец Akikaze, который потопил уже четыре подлодки, первой потопленной из которых была подлодка этого капитана.

В команде возник страх, который спровоцировал попытку смещения капитана.

Стратегические цели, в корне изменяющие расстановку сил на театре военных действий, против тактических целей в виде сохранения ресурсов.

Долгосрочные цели вступили в конфликт с краткосрочными целями.

Знакомая ситуация, не правда ли? Архитектор настаивает на существенных конструктивных преобразованиях системы, сдерживающих развитие системы, в то время как у представителей бизнеса возникает опасение рисков - а вдруг не справятся? А вдруг выйдет дороже? А вдруг это не принесет ожидаемых выгод? А стоит ли оно упущенной выгоды из-за задержки доставки бизнес-фич?

Рискнуть и получить много или жить спокойно и довольствоваться малым?

Это и есть та причина, по которой архитектор должен обладать храбростью.

Главное, чтоб не путать храбрость с глупостью. Обратите внимание, как действовал капитан:
1. Самоподготовка. Он смоделировал бой 200 раз сидя в кабинете.
2. Обучение команды, чтоб она обладала требуемыми навыками.
3. Прототипирование. Испытание нового тактического приема в бою с малозначимой целью.
4. Завоевание авторитета перед командой ("Вот это шкипер! Да, он знает своё дело!"). Т.е. установление и укрепление власти.
5. Коммуникативная психология. Преодоление сопротивления команды (здесь пригодился завоеванный ранее авторитет).

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

А так же концентрацию усилий. От первого боя он уклонился, чтоб сохранить силы для решающей схватки и не обнаружить себя раньше времени.

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

Управление сложностью (главный императив разработки ПО) на примере шахмат:

"Дейкстра пишет, что ни один человек не обладает интеллектом, способным вместить все детали современной компьютерной программы (Dijkstra, 1972), поэтому нам - разработчикам ПО — не следует пытаться охватить всю программу сразу. Вместо этого мы должны попытаться организовать программы так, чтобы можно было безопасно работать с их отдельными фрагментами по очереди. Целью этого является минимизация объема программы, о котором нужно думать в конкретный момент времени. Можете считать это своеобразным умственным жонглированием: чем больше умственных шаров программа заставляет поддерживать в воздухе, тем выше вероятность того, что вы уроните один из них и допустите ошибку при проектировании или кодировании.

На уровне архитектуры ПО сложность проблемы можно снизить, разделив систему на подсистемы. Несколько несложных фрагментов информации понять проще, чем один сложный. В разбиении сложной проблемы на простые фрагменты и заключается цель всех методик проектирования ПО. Чем более независимы подсистемы, тем безопаснее сосредоточиться на одном аспекте сложности в конкретный момент времени. Грамотно определенные объекты разделяют аспекты проблемы так, чтобы вы могли решать их по очереди. Пакеты обеспечивают такое же преимущество на более высоком уровне агрегации.

Стремление к краткости методов программы помогает снизить нагрузку на интеллект. Этому же способствует написание программы в терминах проблемной области, а не низкоуровневых деталей реализации, а также работа на самом высоком уровне абстракции.

Суть сказанного в том, что программисты, компенсирующие изначальные ограничения человеческого ума, пишут более понятный и содержащий меньшее число ошибок код.

Dijkstra pointed out that no one's skull is really big enough to contain a modern computer program (Dijkstra 1972), which means that we as software developers shouldn't try to cram whole programs into our skulls at once; we should try to organize our programs in such a way that we can safely focus on one part of it at a time. The goal is to minimize the amount of a program you have to think about at any one time. You might think of this as mental juggling—the more mental balls the program requires you to keep in the air at once, the more likely you'll drop one of the balls, leading to a design or coding error.

At the software-architecture level, the complexity of a problem is reduced by dividing the system into subsystems. Humans have an easier time comprehending several simple pieces of information than one complicated piece. The goal of all software-design techniques is to break a complicated problem into simple pieces. The more independent the subsystems are, the more you make it safe to focus on one bit of complexity at a time. Carefully defined objects separate concerns so that you can focus on one thing at a time. Packages provide the same benefit at a higher level of aggregation.

Keeping routines short helps reduce your mental workload. Writing programs in terms of the problem domain, rather than in terms of low-level implementation details, and working at the highest level of abstraction reduce the load on your brain.

The bottom line is that programmers who compensate for inherent human limitations write code that's easier for themselves and others to understand and that has fewer errors."

—"Code Complete" 2nd edition by Steve McConnell, перевод: Издательско-торговый дом "Русская Редакция"