Архитектурные границы и зависимости
Основная задача архитектора на проекте - правильно разделить обязанности, провести архитектурные границы, ограничить лишнюю зацепленность и обеспечить нужную связность. Отсюда возникают вопросы: - Как провести границы? - Как определить зависимости? - Как обеспечить управляемость? - и т.д.
Рассмотрением этих вопросов мы сегодня и займемся.
Зависимости
Duration: 10
Существует два основных направления на схемах, отражающих архитектуру уровня кода, это: - направление зависимостей; - направление потока управления;
Основная проблема архитектуры заключается в том, что зависимостей нельзя избежать, но ими можно управлять. Основной императив "инфраструктура должна зависеть от бизнес логики, а не наоборот". Таким образом бизнес логика должна обеспечивать "ядро" функционирования системы.
Границы
Duration: 10
Основная задача архитектора - грануляция система на маскимально "независимые" компоненты. Эта задача достигается за счет проведения границы. Визуально граница на диаграмме выглядит как разделяющая линия, в логическом смысле - это способ сказать "здесь моя территория, я принимаю решение".
Проведение границ - это один из способов разделения обязанностей. Внутри границ должны находится только те вещи, которые реально входят в зону моей ответственности и компетенции. А все неважные вещи, должны выносится за границы.
Границы должны позволять разделить систему на уровни абстракции, чем ближе к вводу/выводу, тем ниже уровень абстракции.
REP, CCP, CRP
Duration: 10
Существует отдельный вопрос - на чем должен фокцсироваться модуль? Как сделать так, чтобы эта фокусировка была максимальной? Это регулируется понятием "связность" (cohasion) и определяется тремя принципами.
Reuse Equivalence Principle - принцип эквивалентного повторного использования Компоненты, включенные в модули должны выпускаться одновременно и является единицей выпуска (расширение компонента)
Common Closure Principle - принцип согласованного изменения Компонент должен включать, то что менятся одновременно, с общей причиной изменения (расширение компонента)
Common Reuse Principle - принцип совместного повторного использования Компонент не должен зависеть от того, что ему не требуется (уменьшение компонента)
Ациклический зависимости
Устойчивость и абстракция
Важно! Есть понятие "технической" устойчивости, т.е. это фактические связи, которые делают компонент устойчивым или нет. А есть "логическая" устойчивость - это когда класс моделирует мало изменчивую часть БЛ. Если они не совпадают - это большая проблема.
Нужно всегда следить, чтобы устойчивые с технической стороны компоненты, были устойчивы и логически.
IOC, DIP, DI
Duration: 10
Существуют разные виды контроля, давайте рассмотрим некоторые из них, которые можно инвертировать:
- контроль зависимостей (DI или IOC 1,2,3 типов);
- контроль потока управления - инверсия потока управления используется во фреймворках, когда клиент меняется местами с сервером;
- контроль ресурсов - используется в системах мониторинга, на высоком уровне абстракции оператор может выполнять автоматизированные таски.