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

• Как провести границы?
• Как определить зависимости?
• Как обеспечить управляемость?
• и т.д.

Рассмотрением этих вопросов мы сегодня и займемся.

Существует два основных направления на схемах, отражающих архитектуру уровня кода, это:

• направление зависимостей;
• направление потока управления;

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

Основная задача архитектора - грануляция система на маскимально "независимые" компоненты. Эта задача достигается за счет проведения границы. Визуально граница на диаграмме выглядит как разделяющая линия, в логическом смысле - это способ сказать "здесь моя территория, я принимаю решение".

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

Границы должны позволять разделить систему на уровни абстракции, чем ближе к вводу/выводу, тем ниже уровень абстракции.

Существует отдельный вопрос - на чем должен фокцсироваться модуль? Как сделать так, чтобы эта фокусировка была максимальной? Это регулируется понятием "связность" (cohasion) и определяется тремя принципами.

• Reuse Equivalence Principle - принцип эквивалентного повторного использования Компоненты, включенные в модули должны выпускаться одновременно и является единицей выпуска (расширение компонента)
• Common Closure Principle - принцип согласованного изменения Компонент должен включать, то что менятся одновременно, с общей причиной изменения (расширение компонента)
• Common Reuse Principle - принцип совместного повторного использования Компонент не должен зависеть от того, что ему не требуется (уменьшение компонента)

Важно! Есть понятие "технической" устойчивости, т.е. это фактические связи, которые делают компонент устойчивым или нет. А есть "логическая" устойчивость - это когда класс моделирует мало изменчивую часть БЛ. Если они не совпадают - это большая проблема.

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

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

• контроль зависимостей (DI или IOC 1,2,3 типов);
• контроль потока управления - инверсия потока управления используется во фреймворках, когда клиент меняется местами с сервером;
• контроль ресурсов - используется в системах мониторинга, на высоком уровне абстракции оператор может выполнять автоматизированные таски.