Это должен знать каждый разработчик: зачем нужна архитектура ПО и какие проблемы она решает

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

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

• Скорость. Разработку замедляют темпы тестирования, добавление новых фич, изменение существующего функционала и т.д.
• Ясность. В слишком большом проекте сложно обнаружить фрагмент кода, функцию, ошибки. Даже может быть неясно, куда внедрять новый функционал.
• Гибкость. Основная цель продукта — его бизнес-логика. Если она завязана на конкретную базу данных или фреймворк, то эта система не гибкая. В таком случае сложно заменить БД или фреймворк другим. А при переносе кода может измениться бизнес-логика и даже потеряться важное для бизнеса правило.
Захоплюючий курс від laba: HR-менеджер.
Розвивайте персонал і підтримуйте бізнес.
Вивчити курс

Причина — код становится слишком связанным, как клубок нитей. Удачно подобранная архитектура поможет избежать подобных проблем. Для упрощения ситуации следует именно на уровне архитектуры «распутать» этот клубок.

Следовательно, упомянутые трудности делятся на следующие группы:

• Политики

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

• Детали

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

Архитектура по своей сути сконцентрирована именно на распределении политик и деталей.

Чтобы определить, к какой группе принадлежит код, подумайте: диктует ли код правила, как что-то в приложении должно работать? Если да, то это политика. Если код — просто реализация того, что должно работать, это детали. К ним относятся, например, фреймворки NestJS и Express.js или библиотеки npm типа Redux.

Многоуровневая архитектура

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

Доменный уровень

Здесь сосредоточены политики:

• бизнес-логика;
• правила;
• сущности;
• сервисы;
• события.

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

Инфраструктурный уровень

Эта прослойка архитектуры предназначена для деталей.

Это могут быть:

• контроллеры;
• роуты;
• базы данных;
• кэш;
• сервисы для внешних API;
• ОRМ.

Именно они заставляют код работать так, как того требуют политики. Детали на этом уровне можно заменять аналогами.

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

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

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

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

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

Порты и адаптеры

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

Параллельно на внешнем уровне создаем адаптеры или конкретные классы и реализации, используя те же интерфейсы. Остается только соединить все это на внешнем уровне. Рассмотрим пример, как это сделать.

Предположим, что вам нужно создать механизм для отправки пользователю мейлов после регистрации. Конфигурация письма и условие его отправки находятся на доменном уровне. Эти параметры касаются того, что и когда должно произойти. Сама же реализация относится к инфраструктурному уровню. В этом случае мы описываем, как должна происходить отправка письма:

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

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

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

Что нам дает правильно подобранная архитектура

Простота тестирования

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

Но перед тем, как заходить слишком далеко, спросите себя: сможете ли «поиздеваться» над написанным кодом? Если вы ссылаетесь на интерфейсы, следите за кодом и делаете его по всем принципам и архитектуре, то ответ «да». А ведь код легко протестировать. В противном случае ответ будет отрицательным.

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

Код инфраструктурного уровня использует веб-сервисы, хранилища объектов, кэши. А это все усложняет тестирование. Хотя за счет удобства проверки доменного уровня вы сэкономите часть времени на тестах.

Гибкость кода

В случае изменения политики можно влиять на детали, ведь они зависят от политики. Но изменение деталей никогда не должно влиять на политику.

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

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

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

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