Чистая архитектура

Введение

Обзор преимуществ и недостатков "Чистой архитетуры" Роберта Мартина Сегодня мы поговорим о том, как:

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

Правило зависимостей

Круги представляют разные круги уровни программного обеспечения. При построении использовались следующие правила:

чем ближе к центру тем выше уровень
чем "горячее" цвет, тем проще и чаще можно изменять элементы уровня
внешние круги - механизмы
внутренние - политики

Зависимости в исходном коде должны быть направлены внутрь, в сторону высокоуровневых политик

Отсюда вытекают следующие ограничения:

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

Данная архитектура не является слоистой, так подразумевает возможность организации горизонтальных связей внутри уровня.

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

Детали

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

Роберт Мартин в своей книге не дал четкого определение того, что нужно считать "Деталью", но у него есть описания того, что является деталью, а что нет. Но можно предположить, что под деталями понимается любая сущность/решение/требование, которое может быть принято на этапе реализации, а не проектирования. Поэтому к деталям относится:

Реляционные базы данных - деталь
Фреймворк - это деталь
Веб - это деталь

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

модели - это абстракция
структуры данных - это абстракция
компоненты - это абстракция
варианты использования - это абстракция
сущности - это абстракция

Упаковка

Многоуровневые архитектуры имеют строгий порядок взаимодествия - сврехку вниз. Само раположение уровней показывает как разместить код в модули, библиотеки и пакеты, которые будут выбраны на практике. Есть два варианта объединения в пакеты:

Упаковка по уровням (web, services, models, entities)
Упаковка по особенностям (пакеты могут объединять разные уровни чистой архитектуры в общую структуру кода - Orders, Customers и т.д.)

Чистая архитектура предлагает гибридный способ упаковки: - Упаковка по компонентам (web, orders)

Тесты

Тесты - это особый код, который есть в проекте. Чистая архитектура не ставит перед собой целью рассматривать тесты как часть архитектуры. Однако, если рассмотреть тесты как значимую часть построения архитектуры на уровне кода, то нужно отметить следующее:

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

Проблема хрупких тестов - заключается в необходимости менять большое количество тестов, при небольшом количестве боевого кода. Хрупкими могут быть тесты UI или другие тесты нижних уровней. Отсюда возникает противоречие - внешний круг не может быть тестами, так как у каждого "круга" должны быть свои тесты.

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

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