Учебник по clean architecture: проектирование приложений корпоративного масштаба

Чистая архитектура — один из основных элементов современного пространства разработки приложений. Эта архитектура, особенно популярная среди разработчиков Java и Android, предназначена для упрощения создания стабильных приложений, даже когда внешние элементы, такие как пользовательский интерфейс, базы данных или внешние API, постоянно меняются. Ориентация на постоянную итерацию стала основным продуктом таких компаний, как Amazon и других компаний FAANG.

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

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

Чистая архитектура — это категория шаблонов проектирования программного обеспечения для архитектуры программного обеспечения, которая следует концепциям чистого кода и реализует принципы SOLID.

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

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

Концепция чистого кода и чистой архитектуры была первоначально изобретена в 2008 году Робертом Мартином, известным в сообществе как «дядя Боб». Его книга «Чистый кодер» стала основным руководством по дизайну современных масштабируемых приложений.

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

Чистая диаграмма с глубоким погружением

В самом простом виде чистую архитектуру можно объяснить следующей схемой:

Эта диаграмма может сначала немного сбивать с толку, поэтому давайте разберемся с ней.

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

Например, основные функции приложения не будут изменены при изменении вашей интерфейсной среды на React to Angular.

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

Изменения в этом слое не повлияют на объекты или несколько внешних слоев. Однако этот слой необходимо будет изменить, если изменятся внешние слои.

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

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

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

Например, он будет полностью содержать архитектуру MVC графического интерфейса.

Эту диаграмму можно понять двумя способами: рассматривать ее как блок-схему или как конус зависимости.

Полная блок-схема выше отлично подходит для понимания пути, по которому данные проходят через программу. Входные данные поступают с левого уровня «Framework and Drivers» и проходят через каналы конфигурации, чтобы достичь API и JOBS.

Этот зеленый раздел «Интерфейсные адаптеры» может обрабатывать ввод с помощью бизнес-логики простого кода и сопоставлять их с одним из утвержденных вариантов использования. Для каждого вида деятельности будет использоваться один сценарий использования. Если ввод не соответствует ожидаемому варианту использования, система отправляет ошибку.

После преобразования в форму, которую ядро ​​может понять, основная логика домена предприятия и приложения завершает задачу и дает результат.

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

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

Диаграмма чистого конуса

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

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

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

Преимущества чистой архитектуры

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

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

• Независимость от фреймворка : чистая архитектура не полагается на инструменты из какой-либо конкретной платформы и не использует фреймворк как зависимость где-либо в коде.

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

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

Это означает, что вы можете мгновенно перейти от базы данных SQL к базе данных NoSQL без изменения кода.

• Независимость от пользовательского интерфейса : каркасы пользовательского интерфейса существуют на самом внешнем уровне и поэтому являются просто представителем данных, передаваемых из внутренних слоев.

От докладчика ничего не зависит, поэтому вы можете изменить структуру пользовательского интерфейса в любой момент.

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

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

Некоторые из этих принципов используются в SOLID и других популярных стратегиях, так что вы, возможно, уже знакомы с некоторыми!

Давайте исследуем каждый.

Общий принцип закрытия

Общий принцип закрытия (CCP) гласит: «Классы в компоненте должны быть закрыты вместе против однотипных изменений. Изменение, затрагивающее компонент, влияет на все классы в этом компоненте и никакие другие компоненты ».

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

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

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

Принцип инверсии зависимостей

Принцип инверсии зависимостей гласит, что:

1. «Модули высокого уровня не должны зависеть от модулей низкого уровня. Оба должны зависеть от абстракций (например, интерфейсов) ».
2. «Абстракции не должны зависеть от деталей. Детали (конкретные реализации) должны зависеть от абстракций ».

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

DIP разделяет высокоуровневые и низкоуровневые компоненты и вместо этого соединяет их с абстракциями. Компоненты высокого и низкого уровня могут по-прежнему извлекать выгоду друг из друга, но изменение одного не должно напрямую нарушать работу другого.

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

Детали — это конкретные закулисные реализации, которые делают поведение программы видимым для пользователя. В программе DIP мы могли бы полностью пересмотреть закулисную реализацию того, как программа достигает своего поведения без ведома пользователя.

Этот процесс известен как рефакторинг.

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

Общий принцип повторного использования

Общий принцип повторного использования (CRP) гласит: «Классы в компоненте повторно используются вместе. Если вы повторно используете один из классов в компоненте, вы повторно используете их все ».

Идея этого принципа заключается в том, что классы внутри вашего компонента должны быть неразделимы. Если вы обнаружите ситуацию, когда вам нужен один класс, а не другие, это признак того, что ваш компонент не выполняет одноразовое использование.

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

Принцип эквивалентности выпуска

Принцип эквивалентности выпуска гласит: «Единица повторного использования, компонент, не может быть меньше единицы выпуска. Эффективное повторное использование требует отслеживания выпусков из системы управления изменениями. Пакет — это эффективная единица повторного использования и выпуска ». Это самый сложный принцип для распаковки, поэтому мы будем разбирать его по частям.

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

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

Что учить дальше

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

• Доменно-ориентированный дизайн (DDD)
• Дизайн, управляемый событиями (EDD)
• Шестиугольная архитектура
• Микросервисная архитектура