Clean Architecture

1. Архитектура программного обеспечения направлена на минимизацию человеческих ресурсов и максимизацию производительности

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

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

Ключевые аспекты хорошей архитектуры:

• Разделение ответственности
• Управление зависимостями
• Абстракция деталей реализации
• Гибкость для учета будущих изменений

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

2. Чистая архитектура отделяет бизнес-правила от внешних деталей

Центр вашего приложения — это не база данных. И это не один или несколько фреймворков, которые вы можете использовать. Центр вашего приложения — это сценарии использования вашего приложения.

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

Ключевые слои в чистой архитектуре:

• Сущности: Бизнес-правила на уровне предприятия
• Сценарии использования: Бизнес-правила, специфичные для приложения
• Адаптеры интерфейса: Преобразование данных между сценариями использования и внешними агентствами
• Фреймворки и драйверы: Внешние инструменты и технологии

Следуя этой структуре, разработчики могут создавать системы, которые:

• Более гибкие и адаптируемые к изменениям
• Легче тестировать и поддерживать
• Менее зависимы от конкретных технологий или фреймворков

3. Принципы SOLID направляют создание гибких и поддерживаемых систем

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

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

Принципы SOLID:

• Принцип единственной ответственности: Класс должен иметь только одну причину для изменения
• Принцип открытости/закрытости: Программные сущности должны быть открыты для расширения, но закрыты для модификации
• Принцип подстановки Лисков: Объекты суперкласса должны быть заменяемы объектами его подклассов без нарушения корректности программы
• Принцип разделения интерфейса: Множество интерфейсов, специфичных для клиента, лучше, чем один универсальный интерфейс
• Принцип инверсии зависимостей: Модули высокого уровня не должны зависеть от модулей низкого уровня; оба должны зависеть от абстракций

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

4. Компоненты — это строительные блоки чистой архитектуры

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

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

Ключевые характеристики хорошо спроектированных компонентов:

• Высокая когезия: Связанная функциональность сгруппирована вместе
• Низкая связность: Минимальные зависимости между компонентами
• Четкие интерфейсы: Хорошо определенные методы взаимодействия
• Независимая развертываемость: Могут быть обновлены или заменены без влияния на другие части системы

Организуя системы в компоненты, архитекторы могут:

• Облегчить параллельную разработку разными командами
• Обеспечить более легкое тестирование и отладку
• Позволить постепенные обновления и улучшения системы
• Улучшить общую масштабируемость и поддерживаемость системы

5. Границы определяют и защищают основную бизнес-логику

На каждой архитектурной границе мы, вероятно, найдем паттерн Humble Object, скрывающийся где-то поблизости.

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

Ключевые аспекты архитектурных границ:

• Использование интерфейсов для определения взаимодействий между слоями
• Инверсия зависимостей для обеспечения того, чтобы зависимости указывали внутрь
• Объекты передачи данных для передачи информации через границы
• Humble объекты для разделения тестируемого поведения от трудно тестируемых компонентов

Устанавливая четкие границы, архитекторы могут:

• Минимизировать влияние изменений во внешних системах или технологиях
• Облегчить тестирование основной бизнес-логики
• Позволить замену деталей реализации без влияния на основную систему
• Улучшить общую гибкость и адаптируемость системы

6. Чистая архитектура облегчает разработку, основанную на тестировании, и независимую развертываемость

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

Тестируемость и гибкость — ключевые факторы. Чистая архитектура продвигает практики, которые делают системы легче тестируемыми и развертываемыми независимо. Разделяя ответственность и управляя зависимостями, становится проще писать модульные тесты для основной бизнес-логики и развертывать различные компоненты системы отдельно.

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

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

Эти характеристики приводят к:

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

7. Фреймворки и базы данных — это детали реализации, а не архитектурные элементы

Фреймворки — это инструменты для использования, а не архитектуры, которым нужно следовать.

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

Ключевые принципы работы с фреймворками и базами данных:

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

Преимущества этого подхода:

• Легче изменить или обновить фреймворки и базы данных
• Основная бизнес-логика остается стабильной, несмотря на внешние изменения
• Снижение зависимости от поставщиков
• Улучшение тестируемости основных компонентов системы

8. Веб — это просто еще один механизм доставки в чистой архитектуре

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

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

Ключевые соображения для веб-приложений в чистой архитектуре:

• Отделяйте веб-специфичный код от основной бизнес-логики
• Используйте адаптеры интерфейса для преобразования между веб-форматами и внутренними структурами данных
• Рассматривайте веб-фреймворки как плагины к основной системе
• Проектируйте сценарии использования, чтобы они были независимы от веб-специфичных вопросов

Преимущества этого подхода:

• Легче адаптировать систему к различным механизмам доставки
• Основная бизнес-логика может быть повторно использована на нескольких платформах
• Упрощенное тестирование бизнес-правил без веб-зависимостей
• Большая гибкость в изменении или обновлении веб-технологий

9. Чистая встроенная архитектура отделяет аппаратные вопросы от бизнес-логики

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

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

Ключевые элементы чистой встроенной архитектуры:

• Аппаратный абстракционный слой (HAL) для изоляции аппаратно-специфичного кода
• Независимая от устройства бизнес-логика
• Четкие интерфейсы между аппаратными и программными компонентами
• Использование инверсии зависимостей для управления аппаратными зависимостями

Преимущества этого подхода в встроенных системах:

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

10. Микросервисы и сервис-ориентированные архитектуры могут извлечь выгоду из принципов чистой архитектуры

Архитектура системы определяется границами, которые разделяют программные элементы друг от друга и ограничивают те, что с одной стороны, от знания о тех, что с другой.

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

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

• Рассматривайте каждый микросервис как ограниченный контекст с собственной чистой архитектурой
• Используйте четко определенные интерфейсы для межсервисного взаимодействия
• Применяйте инверсию зависимостей между сервисами
• Поддерживайте независимую развертываемость сервисов

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

• Улучшенная модульность и масштабируемость всей системы
• Легче понимать и поддерживать отдельные сервисы
• Большая гибкость в развитии и замене сервисов
• Снижение связности между сервисами, что приводит к более надежным системам

Последнее обновление: July 26, 2024