Объяснение чистой архитектуры (часть 1)

На реальном примере в TypeScript

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

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

Вот ссылка на Часть-2, где представлена реализация.

Вступление. (Прочтите эту часть, если хотите узнать о моем пути к изучению чистой архитектуры.)
Почему чистая архитектура?
Концептуальная идея.
Реализация. (Часть 2)
Использованная литература. (Часть 2)

Вступление

Я начал разработку программного обеспечения на C # в качестве фрилансера примерно в 2004 году, а затем присоединился к некоторым компаниям, а также на некоторое время стал соучредителем стартапа и переключился на мир JavaScript с помощью Node.js.

Я наслаждался динамичным миром JavaScript с помощью Node.js, а потом мне понравился TypeScript.

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

Во многих случаях я получал такие фреймворки, как Parse, Loopback или MEAN и т.д. Герметичное соединение и высокое сцепление с другими каркасами. всегда думал о том, как лучше всего построить на этом решение.

Я познакомился с чистой архитектурой, посмотрев видео на YouTube по совпадению, что дядя Боб говорит о чистой архитектуре. Для меня это было все равно, что сбить грузовик. Это было шокирующим, насколько блестящей является Идея, и я выглядел как ответ, который я искал. Затем я получил Книгу Чистой Архитектуры и начал читать много сообщений в блогах.

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

Почему чистая архитектура?

Начнем с цитаты из книги:

Почему по максимуму количество решений не принято? !! Мы, как разработчики, экспериментально знаем, что фреймворки, которые мы выбираем в начале проекта (базы данных или веб-фреймворки и т. Д.), Трудно заменить в течение всего жизненного цикла проекта, и это из-за тесной связи и множества других ранних решений. Одна из распространенных ошибок заключается в том, что мы строим наш проект на основе этих фреймворков, а затем позволяем бизнес-логике обернуться вокруг них.

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

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

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

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

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

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

Дядя Боб подчеркивает, что принципы SOLID объединяются с шаблоном Чистая архитектура, чтобы сформировать удобочитаемое, легко обслуживаемое, масштабируемое и легко развертываемое программное решение.

Концептуальная идея

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

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

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

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

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

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

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

Конфигурация

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

Часть-1 Заключение

Я хочу завершить этот раздел еще одной цитатой из книги «Чистая архитектура»:

В этой цитате есть четыре ключевых момента:

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

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

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