Архитектурные границы и зависимости

preview

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

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

Зависимости

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 типов);
  • контроль потока управления - инверсия потока управления используется во фреймворках, когда клиент меняется местами с сервером;
  • контроль ресурсов - используется в системах мониторинга, на высоком уровне абстракции оператор может выполнять автоматизированные таски.