Чистая архитектура (Clean Architecture), популяризированная Робертом Мартином ("Дядя Боб"), представляет собой набор принципов для организации кода, направленных на создание гибкой, тестируемой и легко поддерживаемой системы.
Основные идеи:
- Разделение на слои: Код делится на концентрические круги, где внутренние круги содержат бизнес-логику, а внешние — детали реализации (UI, базы данных, внешние API).
- Зависимость от внутренних слоев: Внешние слои зависят от внутренних, но не наоборот. Это достигается с помощью принципа инверсии зависимостей.
- Инкапсуляция: Каждый слой скрывает детали своей реализации от внешних слоев.
- Тестируемость: Бизнес-логика, находящаяся в центральных слоях, не зависит от внешних деталей, что делает ее легко тестируемой в изоляции.
- Независимость от фреймворков: Основные правила бизнеса не привязаны к конкретным фреймворкам, UI или базам данных.
Слои (пример):
- Entities: Содержат бизнес-объекты и правила (например, класс
User с бизнес-логикой, связанной с пользователем).
- Use Cases (Interactors): Содержат специфическую для приложения бизнес-логику (например,
GetUserUseCase). Они оркестрируют взаимодействие между Entities и Gateway Interfaces.
- Interface Adapters: Адаптируют данные из внешних источников во формат, понятный Use Cases и Entities (например, Presenters для UI, Gateway Implementations для баз данных).
- Frameworks & Drivers: Внешний слой, содержащий фреймворки (UI, базы данных, веб-сервисы).
Принцип инверсии зависимостей играет ключевую роль. Внутренние слои определяют интерфейсы (Gateway Interfaces), а внешние слои реализуют эти интерфейсы. Это показано на следующей схеме:
plaintext
Стрелки показывают направление зависимостей. Все зависимости нап
Чистая архитектура (Clean Architecture), популяризированная Робертом Мартином ("Дядя Боб"), представляет собой набор принципов для организации кода, направленных на создание гибкой, тестируемой и легко поддерживаемой системы.
Основные идеи:
- Разделение на слои: Код делится на концентрические круги, где внутренние круги содержат бизнес-логику, а внешние — детали реализации (UI, базы данных, внешние API).
- Зависимость от внутренних слоев: Внешние слои зависят от внутренних, но не наоборот. Это достигается с помощью принципа инверсии зависимостей.
- Инкапсуляция: Каждый слой скрывает детали своей реализации от внешних слоев.
- Тестируемость: Бизнес-логика, находящаяся в центральных слоях, не зависит от внешних деталей, что делает ее легко тестируемой в изоляции.
- Независимость от фреймворков: Основные правила бизнеса не привязаны к конкретным фреймворкам, UI или базам данных.
Слои (пример):
- Entities: Содержат бизнес-объекты и правила (например, класс
User с бизнес-логикой, связанной с пользователем).
- Use Cases (Interactors): Содержат специфическую для приложения бизнес-логику (например,
GetUserUseCase). Они оркестрируют взаимодействие между Entities и Gateway Interfaces.
- Interface Adapters: Адаптируют данные из внешних источников во формат, понятный Use Cases и Entities (например, Presenters для UI, Gateway Implementations для баз данных).
- Frameworks & Drivers: Внешний слой, содержащий фреймворки (UI, базы данных, веб-сервисы).
Принцип инверсии зависимостей играет ключевую роль. Внутренние слои определяют интерфейсы (Gateway Interfaces), а внешние слои реализуют эти интерфейсы. Это показано на следующей схеме:
plaintext
Стрелки показывают направление зависимостей. Все зависимости нап
