Подход это не инструкция. Это набор действий, приводящих к определенному результату в подходящих условиях. И которому дали имя. На заре разработки огромное число людей сами изобретали паттерн mvc по тому что это было логично. Ему даже давали разные имена, но чуть была в одном, действия были одними. Рождался паттерн в головах тысяч разработчиков по всему миру и однажды просто прижилась терминология

Agile методологии, архитектура, алгоритмы. Все это было сформулировано сильно после того как стало нормой

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

А зачем вы слово Agile употребляете?

Просто под руки попалось

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

Как объяснить закон Конвея так чтобы он не стал ещё одной теоретической ерундой признаться не знаю. Для меня в бытность студером это было "ну элементарно же алло, зачем это обсуждать". Приобрело и смысл, и зачем обсуждать - после хождений по коопоративным граблям. Что называется сперва не понял, а потом как понял.:)
Мне кажется это применимо ко всем общим моментам, понимание приходит с опытом.

Главный закон:
- строительный блок решения (компонент, сервис, маленький сервис (микросервис)), должен быть максимально независим и слабо связан с другими строительными блоками решения
- стрительный блок должен делать только то, что должен.

Low Coupling и High Cohesion (см. Constantine S Law и GRASP).

Это даст в итоге автономность.

Как и человек. Если человек не найдёт себя и будет проживать не свою жизнь, ничего хорошего не получится. То есть если человек не автономен, то ему и с другими трудно.

Да. Это подчеркивается, через GRASP и SOLID принципы.

Не вполне так, с моей точки зрения. Low Coupling и High Cohesion - это принципы принципов. Базовые принципы, по отношению к которым можно валидировать другие принципы.

SOLID нужен во многом для достижения Low Coupling и High Cohesion.

Давайте строить архитектуру приложений и систем, опираясь на что-то более серьезное чем здравый смысл.

Да и фиг с ними с coupling и cohesion. И другой терминологией. Можно не знать правильных слов и все-равно строить архитектуру, которая будет соответствовать ожиданиям

Чьим ожиданиям? Как я недавно усвоил урок, что мои ожидания это мои проблемы...

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

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

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

Ожидания бизнеса проще всего закрывать в бане

Или в баре. Или с казино, или стрип-клубе, а с кем-то на футбольном матче)