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

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

Наиболее известные программные архитектуры:

• MVC (модель-представление-контроллер)
• MVP (модель-представление-ведущий)
• MVVM (модель-представление-представление-модель)

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

Вот когда на сцену выходит Чистая Архитектура!

Чистая архитектура

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

- Чистая архитектура дяди Боба

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

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

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

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

Приведенный ниже комментарий в книге «Чистая архитектура» четко резюмирует весь этот момент.

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

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

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

Сущность

Сущности — это ваши бизнес-правила, которые могут быть описаны классами, объектами, структурами данных или объединены. Когда происходят изменения в деталях внешнего уровня (например, в потоке операций), маловероятно, что они изменятся.

Случаи использования

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

Интерфейсные адаптеры

Этот уровень преобразует данные из варианта использования для использования в слоях фреймворка, таких как фреймворки GUI, веб-интерфейс и т. д.

Фреймворки и драйверы

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

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

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

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

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

Я создал самое простое приложение TODO с чистой архитектурой на платформе Android. Вы можете найти полный код на GitHub .

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

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

Вот структура слоев, используемая в подходе:

Та же самая многоуровневость отражена в структуре каталогов.

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

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

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

Домен

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

Здесь у нас есть Задача как сущность, которая определяет основную задачу и ее свойства.

Данные

Этот слой определяет взаимодействие с данными. У нас есть TaskDataSource для определения операций над данными. Затем мы определили TaskRepository для объединения нескольких источников данных в один репозиторий и доступа к данным с помощью репозитория.

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

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

вариант использования

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

Ниже приведены варианты использования, определенные для выполнения различных операций с данными:

Рамки

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

Для нашей реализации мы использовали базу данных Room через TaskDataSourceImpl для реализации TaskDataSource.

Презентация

Этот уровень определяет логику представления в коде и то, как представления для конкретной платформы используются для представления данных пользователю. Здесь у нас есть модели представлений, которые вызывают варианты использования, определенные на уровне вариантов использования, и представляют их с помощью представлений Android.

Вот и все!

Подведение итогов

Я надеюсь, что это разъясняет чистую архитектуру и то, как вы можете реализовать ее в разработке для Android.

Вы можете найти полный код примера приложения TODO на GitHub . Поднимите PR, если у вас есть предложения по структуре кода. Вы можете внести свой вклад.

Удачного кодирования!

PS Отдельное спасибо Prem Patel за руководство и Sanat Shukla за поддержку.

Используемые ссылки

История чистой архитектуры