Проектируйте правильно

О, как мы срались с сертифицированными архитектами!.. Их позиция - архитектура решения определяется, в основном, QA и NFR вытекающими из ТРЕБОВАНИЙ КЛИЕНТА. Моя позиция - клиент, если он пошел к архитекторам, в 99% случаев сам не знает чего хочет. И в бОльшей половине случаев - это не отсутствие мозгов у клиента, а отсутствие знаний о будущих событиях (как пойдет бизнес, как отреагируют клиенты, как будет двигаться регуляторика и проч). И поэтому когда мы с умным видом рисуем вытекающие из незнания диаграмы - это попытка не замечать слона в комнате (ну и возможность, если что - оправдаться и не стать крайним за неудачный проект).

Я вижу три столпа хорошей архитектуры. Первый - это опыт в предметной области. Если клиент еще не знает свое будущее, а вы на другом клиенте уже потренировались - то это гигантский плюс к построению нормальной архитектуры и к успеху всего предприятия. Примечание: учитывая Брукса - лучше тренироваться на 2 клиентах. Вторая система - обычно галимый оверинжиниринг, когда делается попытка обобщить опыт с единственного примера.

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

Третий столп - помните, что ваша архитектура должна быть в основном о требованиях, которые в настоящий момент неизвестны и не могут быть легко выявлены. Вы обязаны заложить достаточную гибкость и точки расширения, чтобы реагировать на черных лебедей без переписывания всей системы. Поэтому у нас от кончика пальца до плеча - аж 6 суставов (хотя из соображений теоретической механики должно хватать трех). При этом, закладывать излишнюю гибкость, и предусматривать 20 суставов или делать аналог щупальца осьминога тоже не стоит.

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

По поводу модулей и зависимостей. Я думаю хорошая модель для объяснения и для нахождения плохо-спроектированных модулей это 1 - Coupling/Cohesion - модули должны иметь как можно меньше связей с другими модулям, а связанность должна быть инкапсулирована внутри модулей. 2 - Afferent/Efferent coupling - количество входящих/исходящий зависимостей классов/модулей. Если класс стабильный и от него многие зависят = ок, делать такой класс зависимым от других и следовательно менее стабильным = не ок.

Подробно не расписываю, рекомендую просто погуглить + небольшие книжки Роберта Матрина где он определяет эти понятия, разобраться с типами связанности. Плюсы такой модели в том что есть готовые инструменты которые автоматически подсчитают упомянутые метрики, и дадут хорошую базу для обсуждения возможного рефакторинга. Так же пользу упомянутых моделей легко объяснить исходя из предпосылки что держать в уме содержимое одного модуля проще проще чем содержимое нескольких связанных с собой модулей(к чему может принуждать высокий Coupling)

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

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

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

И к тому, что попытка внедрить любую новую сквозную функциональность упирается в необходимость выделить непредсказуемые ресурсы каждой прикладной команде. И всё равно итог у каждой команды получится по-своему отличающийся от задуманного. В итоге будет обычное «работает — не тронь»...