В предыдущей статье я написал рассказ о Принципе SOLID, который представил Роберт Мартин (дядя Боб). Чистая архитектура - это тоже терминология, которую популяризировал Роберт Мартин (дядя Боб).
В своей книге Чистая архитектура: руководство по структуре и дизайну программного обеспечения известный писатель Роберт К. Мартин (дядя Боб) уделяет проектированию некоторые важные аспекты, такие как тестируемость и независимость фреймворков, баз данных и интерфейсов.
Согласно его статье на blog.cleancoder.com, Чистая архитектура имеет следующие ограничения:
- Независимо от платформ. Архитектура не зависит от наличия какой-либо библиотеки функционального программного обеспечения. Это позволяет вам использовать такие фреймворки в качестве инструментов, вместо того, чтобы загонять вашу систему в их ограниченные ограничения.
- Подходит для тестирования. Бизнес-правила можно тестировать без пользовательского интерфейса, базы данных, веб-сервера или любого другого внешнего элемента.
- Независимо от пользовательского интерфейса. Пользовательский интерфейс можно легко изменить, не меняя остальную часть системы. Веб-интерфейс можно заменить, например, консольным, без изменения бизнес-правил.
- Независимо от базы данных. Вы можете заменить Oracle или SQL Server на Mongo, BigTable, CouchDB или что-то еще. Ваши бизнес-правила не привязаны к базе данных.
- Независимо от каких-либо внешних агентств. На самом деле ваши бизнес-правила просто ничего не знают о внешнем мире.
Используя архитектуру дяди Боба, мы можем разделить наш код на 4 уровня.
Сущности
Сущности инкапсулируют корпоративные бизнес-правила. Сущность может быть объектом с методами или набором структур данных и функций. Это не имеет значения, если сущности могут использоваться множеством различных приложений на предприятии.
- Адресация вашего доменного объекта
- Применяйте только логику, которая применима ко всему объекту в целом (например, проверка формата имени хоста)
- Обычные объекты: без рамок, без аннотаций
Слой вариантов использования
Программное обеспечение на этом уровне содержит бизнес-правила для конкретных приложений. Он инкапсулирует и реализует все варианты использования системы
- Представьте свои бизнес-действия: это то, что вы можете делать с приложением. Ожидайте одного варианта использования для каждого бизнес-действия
- Чистая бизнес-логика, простой код (кроме, может быть, некоторых библиотек утилит)
- Вариант использования не знает, кто его инициировал и как будут представлены результаты (например, может быть на веб-странице, или - возвращен как JSON, или просто зарегистрирован и т. Д.).
- Выбрасывает бизнес-исключения
Контроллер
Программное обеспечение на этом уровне представляет собой набор адаптеров, которые преобразуют данные из формата, наиболее удобного для вариантов использования и сущностей, в формат, наиболее удобный для некоторых внешних агентств, таких как База данных или Интернет.
- Извлекайте и храните данные из нескольких источников (база данных, сетевые устройства, файловая система, сторонние организации и т. Д.) И храните их в них.
- Определите интерфейсы для данных, которые им нужны, чтобы применить некоторую логику. Один или несколько поставщиков данных будут реализовывать интерфейс, но в случае использования неизвестно, откуда берутся данные.
- Реализуйте интерфейсы, определенные вариантом использования.
- Существуют способы взаимодействия с приложением и обычно включают механизм доставки (например, REST API, запланированные задания, графический интерфейс, другие системы).
- Запуск сценария использования и преобразование результата в формат, соответствующий механизму доставки.
- контроллер для MVC
Уровень фреймворков и драйверов
По словам дяди Боба:
Самый внешний уровень обычно состоит из фреймворков и инструментов, таких как база данных, веб-фреймворк и т.д.
- Используйте наиболее подходящий фреймворк (здесь они все равно будут изолированы)
В качестве примера чистой архитектуры я бы хотел использовать пример из mattia-battiston в его репозитории на github, который называется clean-architecture-example
Заключение
Центр вашего приложения - это не база данных. И это не одна или несколько фреймворков, которые вы можете использовать. В центре вашего приложения находятся варианты использования вашего приложения - Unclebob (источник)
Чистая архитектура помогает нам решить или, по крайней мере, смягчить эти основные проблемы при проектировании архитектуры:
- Решения принимаются слишком рано, часто к началу проекта, когда мы меньше всего знаем о проблеме, которую должны решить.
- Это сложно изменить, поэтому, когда мы находим новые предметы первой необходимости, нам нужно выбирать, нужно ли нам их взломать или пройти дорогостоящую и болезненную переделку. Мы в целом знаем, какой из них обычно выигрывает. Лучшие архитектуры - это те, которые позволяют нам отложить принятие конкретного решения и позволяют нам передумать
- Основное внимание уделяется фреймворкам. Платформы - это инструменты, которые нужно использовать, а не архитектуры, которым нужно соответствовать. Фреймворки часто требуют от вас обязательств, но не на вас. Они могут развиваться по-разному, и после этого вы застрянете, придерживаясь их стандартов и особенностей
- Он сосредоточен вокруг базы данных. Мы часто сначала рассматриваем базу данных, а затем создаем вокруг нее платформу CRUD. В конечном итоге мы используем объекты базы данных повсюду и рассматриваем все в терминах таблиц, строк и столбцов.
- Мы концентрируемся на технических аспектах, и когда нас спрашивают о нашей архитектуре, мы делаем такие утверждения, как «это сервлеты, работающие в Tomcat с Oracle db, использующие Spring».
- Это неуловимые вещи, благодаря которым каждое улучшение становится все длиннее и мучительнее
- Бизнес-логика разбросана повсюду, рассредоточена по многочисленным уровням, поэтому при проверке того, как что-то работает, наш единственный вариант - изучить всю кодовую базу. Куда более ужасный, часто его копируют в разных местах
- Поощряет медленные и масштабные тесты. Обычно наш единственный выбор для тестов - это пройти через графический интерфейс, либо потому, что графический интерфейс имеет тонну логики, либо потому, что архитектура не позволяет нам делать иначе. Это делает тесты отложенными до запуска, тяжелыми и хрупкими. Это приводит к тому, что люди не запускают их, а сборка часто ломается
- Выполняется нечасто, потому что сложно внести изменения, не нарушив существующие функции. Люди прибегают к долгоживущим функциональным ветвям, которые интегрируются только в конце и приводят к огромным поставкам вместо небольших инкрементальных.
использованная литература
Https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
Https://www.freecodecamp.org/news/a-quick-introduction-to-clean-architecture-990c014448d2/
Https://eminetto.medium.com/clean-architecture-using-golang-b63587aa5e3f
Https://eltonminetto.dev/post/2020-07-06-clean-architecture-2years-later/
Https://github.com/mattia-battiston/clean-architecture-example