Чистая архитектура. Часть 3

В прошлый раз мы говорили о связанности и сочетаемости компонентов систем, а также обсудили подробнее цели хорошей архитектуры. Сегодня подробнее рассмотрим бизнес‑правила, уровни архитектуры, немного поговорим о шаблонах и тестах.

Глава 20. Бизнес‑правила

Коротко:

  • Бизнес‑правила — это правила или процедуры, которые приносят или сохраняют бизнесу деньги.
  • Специфические для приложения правила — это дополнение к бизнес‑правилам.

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

Сущность — это контейнер, который содержит набор критичных правил и данных для их работы.

Специфические для приложения правила называются юзкейсами. Они описывают модели общения между пользователем и сущностями. Сущности не должны знать ничего о юзкейсах, которые их контролируют (юзкейсы — это дополнения к сущностям).

Юзкейсы зависят от входных данных и производят выходные данные, но при этом не зависят от формы, в которой эти данные передаются.

Глава 21. Говорящая архитектура

Коротко:

  • Архитектура — это не про фреймворки.
  • Хорошая архитектура рассказывает, какую систему она описывает, а не на чём построена.

Фреймворки — это инструмент, а не материал. Архитектура должна основываться на юзкейсах, а не на фреймворках. Хорошая архитектура позволяет откладывать решения о выборе фреймворка и менять их, если придётся.

Веб — это механизм ввода‑вывода.

Хорошая архитектура рассказывает, какую систему она описывает, а не на чём построена.

Глава 22. Чистая архитектура

Коротко, чистая архитектура:

  • не зависит от фреймворков;
  • легко тестируется;
  • не зависит от пользовательского интерфейса;
  • не зависит от базы данных;
  • не зависит от каких‑либо внешних агентов.

Внешние слои могут зависеть от внутренних, но не наоборот: 

Сущности инкапсулируют критичные бизнес‑правила. Юзкейсы содержат правила, специфические для приложения. Адаптеры интерфейсов конвертируют данные из формата, удобного для юзкейсов, в формат удобный для внешних слоёв.

Главы 23–25

Коротко:

  • Сделать систему тестируемой помогает шаблон простого объекта.
  • Скрыть сложную логику можно за фасадами.
  • Стоит почаще задаваться вопросом «а понадобится ли мне это?».

Глава 26. Корневой компонент

Коротко:

  • Корневой компонент — тот, который создаёт, управляет и контролирует все остальные.
  • Корневой компонент должен быть снаружи архитектуры системы.

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

Глава 27. Сервисы

Коротко:

  • Сервисы слабо‑связаны, но так бывает не всегда.
  • Сервисы помогают достичь независимого деплоя, но так тоже бывает не всегда ¯\_(ツ)_/¯
  • Архитектура определяется не сервисами как таковыми, а границами между значимыми компонентами системы.

Глава 28. Тесты

Коротко:

  • Тесты — часть системы.
  • Если тесты сильно связаны с компонентами, то небольшое изменение может уронить сотни тестов.

Что дальше

В шестой части книги описываются детали реализации: БД, веб, фреймворки; а также несколько примеров. Это я рекомендую прочесть внимательно самим.

Вместе с этой книгой советую прочитать пару других:

Предыдущие части:

И ссылки из конспекта:

← Уфа, сентябрь 2018 Самое важное в самокопании →