Фундаментальный подход к программной архитектуре. Паттерны, свойства, проверенные методы

Принимая во внимание все вышеизложенное, архитектор должен ответить на следующие вопросы:

Монолит или распределенная архитектура?

Где должны находиться данные?

Каков будет стиль обмена данными между сервисами: синхронным или асинхронным?

Применение паттерна событий рабочего процесса является одним из способов решить проблему обработки ошибок в асинхронном рабочем процессе

Многоуровневая архитектура относится к архитектурам, разбиваемым по техническому принципу (в отличие от предметного разбиения). Компоненты объединяются в группы не по предметным областям (например, по клиентам), а по своей технической архитектурной роли (например, по представлению или по бизнес-логике). В результате любая конкретная бизнес-область пронизывает все уровни архитектуры.

Крайне сложно предсказать долгосрочные последствия проектных реше-ний, как при разработке программных систем, так и в других инженер-ных дисциплинах. Неизменный совет в большинстве случаев — отдавать предпочтение простым конструкциям — будет хорошей профилактикой защиты от возможных рисков.

В архитектуре нет неправильных ответов, есть только стоящие больших затрат.

Никакие архитектурные решения не должны приниматься в отрыве от команды специалистов по реализации проекта, поскольку это приведет к зловещему антипаттерну Башня из слоновой кости (Ivory Tower Architect).

настраиваемое поведение весьма успешно поддерживается архитектурным стилем микроядер, где нужный результат достигается за счет определения архитектуры подключаемого модуля (плагина)

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

интероперабельность подразумевает простоту интеграции с дру-гими системами, что, в свою очередь, обозначает наличие опубликованных, задокументированных API-интерфейсов.

Правомерность - Каковы правовые ограничения работы системы (защита данных, закон Сарбейнса — Оксли, GDPR и т. д.). Сохранение каких прав нужно компании?
Имеются ли какие-либо правила относительно способа создания или раз-вертывания приложения?

Слишком удаленные в направлении верхнего правого угла классы входят в так называемую зону бесполезности (zone of uselessness): слиш-ком абстрактный код создает трудности при использовании. С другой стороны, код, далеко отстоящий от прямой в направлении нижнего левого угла, попадает в зону мучений (zone of pain): слишком большая доля реализации и недостаточная абстрактность приводят к хрупкости кода и сложности в сопровождении

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

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

Еще одна производная метрика, нестабильность, определяется как отношение эфферентной связанности к сумме эфферентной и афферентной связанности. Метрика нестабильности определяет волатильность кодовой базы. Чем выше нестабильность, тем легче кодовая база ломается при внесении изменений, по-скольку у нее высокая степень связанности.

Афферентная связанность измеряется количеством входящих соединений с элементом кода (компонентом, классом, функцией и т. д.). Эфферентная связанность измеряется количеством исходящих соединений с другими фраг-ментами кода.

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

LCOM - Количество наборов методов, не использующих совместно общие поля.