От N-уровня к чистой архитектуре с .NET

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

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

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

N-уровневая архитектура

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

Многоуровневая архитектура, также известная как N-уровневая архитектура, предлагает множество преимуществ по сравнению с монолитной архитектурой. Давайте посмотрим на некоторые из них:

• Удобство обслуживания: вы можете управлять каждым уровнем отдельно, добавляя или изменяя каждый уровень, не затрагивая другие уровни.

• Масштабируемость: Если вам нужно добавить больше ресурсов, вы можете сделать это для каждого уровня, не затрагивая другие уровни.

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

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

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

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

Впервые она была описана [дядей Бобом] (https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html) как чистая архитектура в 2012 году. похожие архитектуры с теми же концепциями:

• [Гексагональная архитектура] (https://en.wikipedia.org/wiki/Hexagonal_architecture_(software))

• [Луковая архитектура] (https://jeffreypalermo.com/2008/07/the-onion-architecture-part-1/)

• [Дизайн, ориентированный на домен (DDD)] (https://www.domainlanguage.com/ddd/)

• Архитектура вертикального среза

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

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

Модель домена

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

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

Службы доменов и приложений

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

Пользовательский интерфейс. Тесты. Инфраструктура

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

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

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

Пример решения

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

Прежде всего, давайте посмотрим на структуру проекта Core. Он содержит папку Entities с моделями домена. Папка Interfaces с определением интерфейсов, необходимых для функционирования домена. Папка Services, которая содержит службы для управления объектом домена. Папка Common с некоторыми общими классами, такими как исключения, помощники и т. д.

Проект «Инфраструктура» содержит реализацию интерфейса контекста базы данных для доступа к базе данных и миграции для управления изменениями базы данных.

Проект Web API содержит службу REST для доступа к функциям пользователя. Здесь UserModel.cs содержит класс DTO для передачи данных от клиента (веб-API) в домен.

Вся работа по внедрению зависимостей выполняется в файле Startup.cs:

```csharp

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

public void ConfigureServices (службы IServiceCollection)

services.AddControllers();

services.AddSwaggerGen(c =>

c.SwaggerDoc("v1", new OpenApiInfo {Title = "CleanArchitecture.Sample.Api", Version = "v1"});

services.AddSingleton(Configuration.GetSection(PostgresSettings.SectionName).Get());

services.AddScoped();

// регистрируем контекст БД приложения

services.AddApplicationDbContext(Конфигурация);

Резюме

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