Чистая архитектура. Часть 3
В прошлый раз мы говорили о связанности и сочетаемости компонентов систем, а также обсудили подробнее цели хорошей архитектуры. Сегодня подробнее рассмотрим бизнес-правила, уровни архитектуры, немного поговорим о шаблонах и тестах.
Глава 20. Бизнес-правила
Коротко:
- Бизнес-правила — это правила или процедуры, которые приносят или сохраняют бизнесу деньги.
- Специфические для приложения правила — это дополнение к бизнес-правилам.
Бизнес-правила — это правила или процедуры, которые приносят или сохраняют бизнесу деньги, при этом неважно, выполнены эти процедуры на компьютере или вручную. Такие правила называют критичными правилами, а данные, с которыми работают эти правила — критичными данными.
Сущность — это контейнер, который содержит набор критичных правил и данных для их работы.
Специфические для приложения правила называются юзкейсами. Они описывают модели общения между пользователем и сущностями. Сущности не должны знать ничего о юзкейсах, которые их контролируют (юзкейсы — это дополнения к сущностям).
Юзкейсы зависят от входных данных и производят выходные данные, но при этом не зависят от формы, в которой эти данные передаются.
Глава 21. Говорящая архитектура
Коротко:
- Архитектура — это не про фреймворки.
- Хорошая архитектура рассказывает, какую систему она описывает, а не на чём построена.
Фреймворки — это инструмент, а не материал. Архитектура должна основываться на юзкейсах, а не на фреймворках. Хорошая архитектура позволяет откладывать решения о выборе фреймворка и менять их, если придётся.
Веб — это механизм ввода-вывода.
Хорошая архитектура рассказывает, какую систему она описывает, а не на чём построена.
Глава 22. Чистая архитектура
Коротко, чистая архитектура:
- не зависит от фреймворков;
- легко тестируется;
- не зависит от пользовательского интерфейса;
- не зависит от базы данных;
- не зависит от каких-либо внешних агентов.
Внешние слои могут зависеть от внутренних, но не наоборот:
Сущности инкапсулируют критичные бизнес-правила. Юзкейсы содержат правила, специфические для приложения. Адаптеры интерфейсов конвертируют данные из формата, удобного для юзкейсов, в формат удобный для внешних слоёв.
Главы 23–25
Коротко:
- Сделать систему тестируемой помогает шаблон простого объекта.
- Скрыть сложную логику можно за фасадами.
- Стоит почаще задаваться вопросом «а понадобится ли мне это?».
Глава 26. Корневой компонент
Коротко:
- Корневой компонент — тот, который создаёт, управляет и контролирует все остальные.
- Корневой компонент должен быть снаружи архитектуры системы.
Входная точка в приложение — корневой компонент, тот, который создаёт, управляет и контролирует все остальные. О нём следует думать, как о плагине к приложению в целом. Этот плагин задаёт начальные условия, настройки, подтягивает необходимые внешние ресурсы, а затем передаёт это всё приложению. Он должен быть как бы снаружи архитектуры системы.
Глава 27. Сервисы
Коротко:
- Сервисы слабо-связаны, но так бывает не всегда.
- Сервисы помогают достичь независимого деплоя, но так тоже бывает не всегда ¯\_(ツ)_/¯
- Архитектура определяется не сервисами как таковыми, а границами между значимыми компонентами системы.
Глава 28. Тесты
Коротко:
- Тесты — часть системы.
- Если тесты сильно связаны с компонентами, то небольшое изменение может уронить сотни тестов.
Что дальше
В шестой части книги описываются детали реализации: БД, веб, фреймворки; а также несколько примеров. Это я рекомендую прочесть внимательно самим.
Вместе с этой книгой советую прочитать пару других:
Предыдущие части:
И ссылки из конспекта: