Table of Contents

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

Что такое чистая архитектура?

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

Этот подход не является радикально новым — он в значительной степени опирается на более ранние шаблоны, такие как шестиугольная архитектура (Алистэр Кокберн), луковая архитектура (Джеффри Палермо) и дизайн, управляемый доменом (Эрик Эванс). То, что чистая архитектура приносит в таблицу, — это четкий, повторяемый набор правил, которые может принять любая команда, независимо от языка или структуры. Самым железным правилом является правило зависимости : зависимости могут указывать только внутрь. Код во внешних слоях может зависеть от внутренних слоев, но ничто во внутренних слоях никогда не зависит от того, что находится снаружи.

Применяя это правило, разработчики гарантируют, что изменения в фреймворках, базах данных или технологиях пользовательского интерфейса не будут распространяться внутрь, чтобы повредить основную бизнес-логику. Система становится принципиально устойчивой к технологическому оттоку.

Основные принципы чистой архитектуры

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

1.Независимость от рамок

Фреймворк — это инструмент, а не основа вашей системы. В чистой архитектуре ваша бизнес-логика не должна быть жестко привязана к конкретной структуре. Например, если вы создаете веб-приложение с такой структурой, как React, Angular или Vue, логика основного домена не должна импортировать компоненты React или справочные службы Angular. Вместо этого фреймворк следует рассматривать как проблему внешнего уровня, которая подключается к четко определенным интерфейсам. Эта независимость позволяет обновлять, заменять или даже удалять структуру без переписывания кода, который имеет наибольшее значение.

2. Проверяемость

Когда бизнес-правила изолированы от внешних зависимостей, они становятся тривиально проверяемыми. Можно писать единичные тесты для сущностей и сценариев использования без вскручивания базы данных, насмешки над HTTP-сервером или загрузки пользовательского интерфейса. Эта скорость и надежность тестирования побуждает разработчиков тестировать чаще и раньше, улавливая ошибки до их эскалации. Более того, поскольку внешние слои (такие как базы данных и API) также разработаны вокруг интерфейсов, вы можете легко писать интеграционные тесты, которые проверяют код клея без необходимости полной системы в Интернете.

3. Разделение озабоченностей

Чистая архитектура делит систему на слои, каждый из которых несет определенную ответственность. Внутренний слой (]Сущности ) содержит общекорпоративные бизнес-правила. Следующий слой (]Использовать Кейсы) обрабатывает рабочие процессы, специфичные для приложений. Далее, Адаптеры интерфейса преобразуют данные между форматами — например, преобразовывая JSON из запроса REST в формат, который может потреблять сценарий использования. Наконец, самый внешний слой (]Рамки и драйверы состоит из деталей, таких как драйвер базы данных, веб-сервер и набор инструментов пользовательского интерфейса. Сохраняя эти проблемы отдельно, вы избегаете кода спагетти, где бизнес-логика завалена SQL-запросами и обработкой HTTP-запросов.

4.Правило зависимости

Это правило является клеем, который удерживает архитектуру вместе. Оно гласит, что зависимости исходного кода всегда должны указывать внутрь: от внешних слоев к внутренним слоям. Ни один внутренний слой никогда не должен знать о внешнем слое. На практике это означает, что интерфейсы, определенные в случаях использования и объекты, принадлежат этим внутренним слоям. Внешние слои реализуют эти интерфейсы - они не диктуют их. Например, если сценарий использования должен спасти пользователя, он определяет интерфейс. Адаптер базы данных (во внешнем слое) реализует этот интерфейс. Для примера никогда не импортирует фактический адаптер базы данных; это зависит только от интерфейса. Эта инверсия управления делает систему отделенной и проверяемой.

Слои чистой архитектуры

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

Предприятия (Правила предпринимательства)

Сущности являются наиболее стабильной частью системы. Они инкапсулируют основные бизнес-правила, которые применимы во всей организации. Например, в банковской системе, объект будет содержать методы, такие как и , которые обеспечивают инварианты, такие как «баланс никогда не должен быть ниже нуля». Сущности, как правило, простые объекты или структуры без внешних зависимостей. Они не знают о базах данных, файловых системах или веб-фреймворках. Они представляют собой окончательную бизнес-модель.

Случаи использования (правила применения бизнеса)

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

Адаптер интерфейса

Этот уровень преобразует данные между наиболее удобным для использования форматом и объектами (обычно простыми структурами данных) и форматом, требуемым внешними агентствами.

  • Контроллеры , которые анализируют HTTP-запросы и называют соответствующий вариант использования.
  • Презентеры, которые преобразуют выходной вариант использования в формат, подходящий для пользовательского интерфейса, например модель просмотра.
  • шлюзы базы данных , которые реализуют репозиторийные интерфейсы и осуществляют перевод между данными сущности и операциями SQL или NoSQL.
  • API-клиенты-адаптеры, которые вызывают внешние сервисы и преобразуют ответы в структуры данных внутреннего слоя.

Адаптерный слой — это то место, где живет большая часть кода «клей», а также слой, который имеет тенденцию чаще всего меняться по мере развития внешних технологий.

Рамки и драйверы

Внешнее кольцо содержит все конкретные технологии, которые использует система: веб-сервер (например, Express, Django, Spring Boot), систему управления базами данных (например, PostgreSQL, MongoDB), UI-фреймворк (например, React, Angular) и т. Д. Этот слой должен быть максимально тонким. Его основная задача - подключить приложение, введя соответствующие реализации в адаптеры интерфейса и варианты использования. Рамки и драйверы могут быть заменены с минимальным воздействием на внутренние слои, пока контракт (интерфейс) остается неизменным.

Преимущества использования чистой архитектуры

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

  • Устойчивость: Когда вам нужно изменить функцию, вы изменяете только соответствующий вариант использования и его сущности — не все приложение. Поскольку зависимости направлены внутрь, изменения внешних слоев (например, замена базы данных) редко каскадируются в бизнес-логику.
  • Проверяемость: Как упоминалось ранее, низкая связь означает, что вы можете тестировать бизнес-правила изолированно, не создавая полной среды. Это приводит к более быстрым циклам обратной связи и более высокой уверенности в коде.
  • Гибкость: Вы можете отложить принятие решений об инфраструктуре. Например, вы можете начать с простой файловой настойчивости и позже перейти на реляционную базу данных без переписывания бизнес-логики, пока интерфейс репозитория остается прежним.
  • Масштабируемость: Чистая архитектура не автоматически делает вашу систему масштабируемой горизонтально, но она поддерживает масштабируемость команды. Разделяя проблемы на слои, разные члены команды (или даже разные команды) могут работать над пользовательским интерфейсом, базой данных и бизнес-логикой одновременно, не наступая друг на друга.
  • Набор и сотрудничество: Новые разработчики могут быстро понять общую структуру, потому что архитектура следует хорошо известному шаблону. Они могут погружаться в конкретные слои без необходимости понимать всю кодовую базу.

Для более глубокого погружения в мотивацию этого шаблона вы можете прочитать оригинальную статью Роберта Мартина в блоге «Чистая архитектура» или изучить дискуссию Мартина Фаулера о предметно-ориентированной наблюдении , которая дополняет философию чистой архитектуры.

Реализация чистой архитектуры на практике

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

Шаг 1: Определите и изолируйте основной домен

Начните с изучения существующего кода, чтобы найти чистые бизнес-правила. Это те части, которые все равно будут иметь смысл, если вы завтра замените базу данных или пользовательский интерфейс. Извлеките их в отдельный модуль (например, пакет, папку или микросервис) без внешних зависимостей. Этот модуль станет вашими объектами и вариантами использования.

Шаг 2: Определите интерфейсы для внешних взаимодействий

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

Шаг 3: Создайте адаптеры, которые реализуют эти интерфейсы

Теперь создайте конкретные классы во внешних слоях, которые реализуют интерфейсы. Для адаптера базы данных это может быть класс хранилища, который использует ваш ORM или сырой SQL. Для адаптера пользовательского интерфейса это может быть контроллер и ведущий, который преобразует данные для просмотра веб-страниц. Ключ заключается в том, чтобы ядро никогда не импортировало эти адаптеры напрямую.

Шаг 4: Проведите все вместе в каркасном слое

Используйте инъекцию зависимости - будь то через контейнер, корень композиции или ручную проводку - для подключения адаптеров к ядру при запуске. Это ответственность самого внешнего слоя. Например, в типичном веб-приложении основная точка входа создает адаптер базы данных, сценарий использования и контроллер, а затем запускает сервер. Ядро остается незаметным для этих конкретных классов.

Шаг 5: Применяйте непрерывный рефакторинг

Чистая архитектура не является одноразовым усилием. По мере добавления функций постоянно проверяйте, что новый код не нарушает правило зависимости. Используйте инструменты для обеспечения соблюдения архитектурных границ (например, ArchUnit для Java или PHPStan с пользовательскими правилами для PHP). Регулярно извлекайте дублированную логику в варианты использования и объекты и выдвигайте код, специфичный для фреймворка, наружу.

Обычные подводные камни, чтобы избежать

  • Сверхинженерные небольшие проекты: Чистая архитектура добавляет опосредованность. Для простого приложения CRUD с одним вариантом использования и без ожидаемых изменений накладные расходы могут не стоить этого. Используйте свое суждение.
  • Утечка фреймворкового кода в ядро: На удивление легко импортировать утилиту фреймворка из удобства. Например, используя аннотацию ORM в классе объектов. Всегда запускайте свой основной модуль в качестве отдельной библиотеки, чтобы убедиться, что он не имеет внешних зависимостей.
  • Создание слишком большого количества интерфейсов преждевременно: Вам не нужен интерфейс для каждого отдельного класса. Только абстрагируйте то, что вы ожидаете изменить. Начните с основных внешних границ (база данных, пользовательский интерфейс, файловая система) и обобщите позже, если это необходимо.
  • Игнорирование границ обработки ошибок: Как исключения выбрасываются и попадаются через границы уровней требует тщательного проектирования. Внутренние слои должны бросать бизнес-исключения, которые имеют значение для ядра. Внешние адаптеры преобразуют их в ошибки, характерные для структуры (например, HTTP 500) без ядра, когда-либо знающего о протоколе HTTP.

Пример из реального мира: простая система обработки заказов

Рассмотрим приложение для электронной коммерции, которое должно разместить заказ. В подходе чистой архитектуры:

  • Сущности: , , с бизнес-правилами, такими как «заказ должен иметь по крайней мере один элемент» и «акции продукта не могут идти отрицательно».
  • Использовать Случай: получает запрос, содержащий идентификатор клиента и список продуктов. Он вызывает интерфейс для сохранения заказа и для обновления запасов. Он также может вызвать интерфейс для оповещения клиента.
  • Адаптеры интерфейса: A извлекает данные из HTTP-запроса, вызывает вариант использования, а затем a преобразует результат в ответ JSON. A реализует с использованием SQL. реализует через сторонний API.
  • Рамки и драйверы: Корень композиции настраивает веб-сервер, инициализирует пул соединений с базой данных и связывает все зависимости вместе. Веб-фреймворк (например, Express.js или Spring Boot) появляется только в этом внешнем кольце.

Если позже вы решите перейти с PostgreSQL на MongoDB, вам нужно только написать новый и обновить корень композиции. Случай использования и сущности остаются нетронутыми. Если вы хотите добавить новый канал уведомлений, такой как SMS, вы создаете другой адаптер и регистрируете его — снова без изменения ядра.

Когда следует применять чистую архитектуру?

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

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

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

Заключение

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

Для дальнейшего чтения по моделированию доменов и чистой архитектуре на конкретных языках программирования вы можете обратиться к Сообществу дизайна, управляемого доменом или явной статье об архитектуре Герберто Грасы , которая связывает вместе несколько шаблонов.