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

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

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

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

Происхождение и концепции

Концепция этой архитектуры была создана Робертом Мартином в 2012 году и предложена в его книге «Чистая архитектура: руководство мастера по структуре и дизайну программного обеспечения». Эта архитектура программного обеспечения сосредоточена на предметной области и может применяться с любым языком программирования.

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

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

Эта круговая схема представляет многоуровневую структуру Чистой Архитектуры. Он состоит из 3 уровней: домен, приложение и инфраструктура. Давайте посмотрим один за другим.

Слой Domain расположен в центре структуры. На изображении выше вы можете видеть, что объекты размещены там, и именно здесь применяются корпоративные правила. Но что такое сущности и «правила предприятия»?

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

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

Что касается разработки программного обеспечения, то здесь есть процесс выявления требований, который отвечает за перевод того, что нужно клиенту системы (включая бизнес-правила), в то, что является явными потребностями в разработке программного обеспечения (требованиями). Реализация решений требований — это то, что мы называем «вариантами использования».

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

После просмотра каждого уровня вам может быть интересно узнать о зеленом разделе «Адаптеры интерфейса» на изображении выше. Этот раздел используется для создания способов подключения инфраструктуры и приложения, поскольку они не связаны напрямую. Для осуществления этого взаимодействия можно использовать некоторые концепции, такие как Контроллеры для точек входа, Шлюзы или Репозитории для подключения к базе данных и внешним API и т. д. . Стоит учитывать, что здесь интерфейсы используются для создания своего рода контрактов и только затем для создания реализаций, которые будут использоваться в сценариях использования (которые можно использовать с внедрением зависимостей). уже упоминалось выше).

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

Пример использования

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

  • Регистрация и аутентификация клиентов
  • Запросить новый пароль, если клиент его забудет
  • Депозит и снятие денег
  • Показать текущий баланс
  • Показать финансовый отчет

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

Во-первых, вы можете смоделировать данные на основе приведенных выше требований:

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

  • Клиент должен иметь уникальную информацию, позволяющую его идентифицировать, например, номер документа (в зависимости от страны, в которой работает банк) или номер лицевого счета;
  • Для аутентификации клиента ему понадобится пароль;
  • У него должно быть доступное значение баланса;
  • Каждая транзакция должна отслеживаться, чтобы получить финансовый отчет, который показывает нам необходимость модели транзакций;
  • Для восстановления пароля клиента мы будем использовать адрес электронной почты, тогда адрес электронной почты также должен быть предоставлен клиентом и должен быть уникальным для каждого клиента;
  • Чтобы помочь системе в почтовых сервисах, добавим свойство name. Таким образом, мы можем настроить наши сообщения.

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

  • Тип транзакции (ввод или вывод);
  • Стоимость сделки;
  • Необязательное описание транзакции.

Кроме того, в качестве хорошей практики для идентификации каждого экземпляра наших моделей все модели будут иметь свойство «id». Кроме того, чтобы наша система отслеживала данные, модели клиентов и транзакций будут иметь свойство «createdAt», которое будет храниться при создании информации.

Наши модели — это наши сущности, и они следующие:

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

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

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

  • Войти Клиент
  • Выйти Клиент
  • Зарегистрировать клиента
  • Обновить информацию о клиенте
  • Изменить пароль клиента
  • Восстановить пароль клиента
  • Сумма сделки
  • Получить баланс клиента
  • Получить финансовый отчет клиента

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

Наконец, на уровне Инфраструктура мы оцениваем фреймворки, библиотеки и сервисы, которые можем использовать для реализации нашего приложения, на основе структуры, которую мы ранее создали на других уровнях. Здесь вы и ваша команда решите, использовать ли Python, PHP, NodeJS или любой другой язык в проекте или использовать FastAPI, Django или Flask и т. д.

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

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

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

Получайте удовольствие от практики!