В предыдущей статье я написал рассказ о Принципе SOLID, который представил Роберт Мартин (дядя Боб). Чистая архитектура - это тоже терминология, которую популяризировал Роберт Мартин (дядя Боб).

В своей книге Чистая архитектура: руководство по структуре и дизайну программного обеспечения известный писатель Роберт К. Мартин (дядя Боб) уделяет проектированию некоторые важные аспекты, такие как тестируемость и независимость фреймворков, баз данных и интерфейсов.

Согласно его статье на blog.cleancoder.com, Чистая архитектура имеет следующие ограничения:

  1. Независимо от платформ. Архитектура не зависит от наличия какой-либо библиотеки функционального программного обеспечения. Это позволяет вам использовать такие фреймворки в качестве инструментов, вместо того, чтобы загонять вашу систему в их ограниченные ограничения.
  2. Подходит для тестирования. Бизнес-правила можно тестировать без пользовательского интерфейса, базы данных, веб-сервера или любого другого внешнего элемента.
  3. Независимо от пользовательского интерфейса. Пользовательский интерфейс можно легко изменить, не меняя остальную часть системы. Веб-интерфейс можно заменить, например, консольным, без изменения бизнес-правил.
  4. Независимо от базы данных. Вы можете заменить Oracle или SQL Server на Mongo, BigTable, CouchDB или что-то еще. Ваши бизнес-правила не привязаны к базе данных.
  5. Независимо от каких-либо внешних агентств. На самом деле ваши бизнес-правила просто ничего не знают о внешнем мире.

Используя архитектуру дяди Боба, мы можем разделить наш код на 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