Хорошая архитектура:
Между дизайном (результатом проектирования) и архитектурой нет никакой разницы.
Цель проектирования - минимизация человеческих ресурсов, необходимых для создания и поддержки программных продуктов. Мера усилий по написанию и сопровождению - отличный индикатор качества архитектуры. В случае с хорошей архитектурой эта мера невелика на старте и остаётся низкой на протяжении всего срока жизни продукта.
Штука в том, что каждая новая фича обладает “присущей сложностью” (неснижаемой), это означает, что в любом случае нужно написать какой-то объем кода, реализующий фичу (примечательно, что этот код рассматривается как совершенно новый, т.е., расширяющий, а не изменяющий ранее написанный код, см. Open-Closed Principle и Обязательно следовать OCP при изменениях кода). Но есть еще и “привнесенная сложность”, выраженная в объеме кода, который нужно написать / изменить, чтобы встроить фичу в текущий код (набор предположений и ограничений, выраженный в коде). Хорошая архитектура уменьшает требуемые для реализации фичи усилия за счет снижения “привнесенной сложности”.
(Время на разработку + деньги + усилия) = Стоимость. Они дают возможность оценивать архитектуру ПО физическими показателями.
Хорошая архитектура удовлетворяет потребности пользователей, разработчиков и владельцев не только в конкретный момент времени, но и с течением времени. Она гарантирует, что вносимые в ПО изменения не будут затратными.
Хорошая архитектура - всегда “кричащая” (screaming acrhitecture) - она явно заявляет о своем бизнес-смысле в каждой детали своей реализации.
Признак хорошей архитектуры - незначительный объем вносимых в существующий код изменений при реализации новой фичи.
Хорошая архитектура - это разделение кода на компоненты таким образом, что связанность, возникающая при их переиспользовании, создает как можно меньше препятствий для внесения изменений 1
Плохая архитектура:
Пример с нелинейным ростом количества инженеров на фоне приближающейся к нулю эффективности их труда. Соответственно, прирост количества строк кода становится все меньше, а стоимость каждой следующей строки - все больше. Чем-то похоже на посыл Брукса в “Мифическом человеко-месяце” - большее количество разработчиков замедляет разработку.
Связи:
- входит в Чистая архитектура - Мартин, Роберт - Чистая архитектура
- упоминается в Архитектура ПО в Spring 5 - Архитектура ПО и Spring 5
Mental maintainability model by S.Kapralov