Современная программная инженерия — Часть 1: Проектирование систем

год назад·11 мин. на чтение

Серия статей о современной разработке программного обеспечения

В ранние времена (конце 80-х и начале 90-х) разработка программного обеспечения в основном заключалась в программном обеспечении, которое работало локально на вашем компьютере или на мейнфреймах со значительно большей вычислительной мощностью, если у вас был к нему доступ. Сегодня большая часть разрабатываемого программного обеспечения либо работает в облаке, либо работает на устройстве, требующем доступа к облаку, либо поддерживает другое программное обеспечение, которое также работает в облаке. Очень редко случается работать над программной системой, которая работает в ограниченном пространстве (например, встроенные программные системы), которые не имеют доступа к более мощной вычислительной платформе в другом месте. Системы бухгалтерского учета теперь обрабатывают кучи данных, размещенных на собственном железе либо в хранилище данных. В системах продаж теперь отношения с клиентами управляются третьей стороной с помощью плагинов, разработанных еще большим количеством сторонних или собственных разработчиков.
Но как эти программные системы создаются сегодня, чтобы обслуживать сотни миллионов пользователей, сохраняя при этом производительность и отзывчивость, которые мы привыкли ожидать от программного обеспечения? В этой статье поговорим о системном проектировании, о том, как оно стал важной частью современной практики разработки программного обеспечения и как оно станет одной из ключевых областей, в которых инженеры-программисты все еще могут приносить пользу в краткосрочной и среднесрочной перспективе.

Важность проектирования систем

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

Компоненты проектирования системы

Когда мы говорим о проектировании системы, обычно это влечет за собой несколько компонентов:
  • Архитектура — как выглядит решение в целом? Включает ли он в себя несколько подсистем? Есть ли отдельные компоненты, составляющие единое целое? Как они взаимодействуют и как они связаны друг с другом?
  • Топология — есть ли в решении многоуровневая структура? Если это распределенная система, то где службы компонентов расположены физически или логически по отношению друг к другу?
  • Низкоуровневое проектирование — Какие интерфейсы вы определили, через которые взаимодействуют различные части систем? Существуют ли конкретные алгоритмы, которые вы используете для решения ключевых аспектов решения (производительность, эффективность, пропускная способность, устойчивость и т. д.)?
Это помогает понять в первую очередь такие вещи, как: является ли система самодостаточной (т.е. не будет иметь доступа к внешним ресурсам) или она распределена? Будет ли у него пользовательский интерфейс или он будет неинтерактивным (например, генерирует ли он распечатанный отчет или потребует участия человека или другой системы во время его работы)? Нужно ли обрабатывать много трафика? Предназначен ли он для использования только десятью людьми в любой момент времени, или 10 миллионов пользователей будут использовать его в любой момент времени? Как только вы получите ответы на некоторые из этих вопросов, принятие решений на основе принципов проектирования системы станет проще.

Принципы проектирования системы

Современные системы нуждаются в масштабировании — от однопользовательской системы до системы, которая должна быть в состоянии обрабатывать тысячи и даже миллионы пользователей одновременно. Поэтому появились несколько ключевых принципов проектирования программных систем. Вот некоторые из них, которые мы рассмотрим в этой статье:
  • Масштабируемость
  • Надёжность
  • Поддерживаемость
  • Доступность
  • Безопасность

Масштабируемость

Система является масштабируемой, если она может быть развернута для обработки роста нагрузки при пропорциональном росте ресурсов. Коэффициент масштабирования системы определяется как рост количества ресурсов, необходимых для обслуживания, рост нагрузки на систему. Мы сталкиваемся с двумя типичными случаями масштабирования с программными системами: вертикальное масштабирование и горизонтальное масштабирование. Вертикальное масштабирование относится к предоставлению программной системе большего запаса или ресурсов одного компьютера для обработки растущих требований. Рассмотрим случай сетевого устройства хранения данных. Чем больше места для хранения вы предоставляете с помощью устройства, тем больше данных оно может хранить. Если он необходим для обработки большего количества одновременных подключений и операций ввода-вывода (IOPS), обычно требуется добавить больше вычислительной мощности и сетевых интерфейсов, чтобы справиться с возросшей нагрузкой. Горизонтальное масштабирование относится к репликации системы или нескольких компьютеров с копиями программного обеспечения для обработки растущих требований. Рассмотрим случай сервера статического веб-содержимого, скрытого за подсистемой балансировки нагрузки. Добавление дополнительных серверов позволяет большему количеству клиентов подключаться и загружать контент с веб-серверов, а когда нагрузка спадает, количество веб-серверов может быть уменьшено до нужного размера для текущего спроса. Некоторые системы могут обрабатывать гибридное или диагональное масштабирование. Например, некоторые архитектуры распределенных баз данных позволяют разделять вычислительные узлы и узлы хранения, чтобы рабочие нагрузки с большими вычислительными ресурсами могли использовать узлы с большим количеством вычислительных ресурсов. В отличие от этого, тяжелые рабочие нагрузки операций ввода-вывода в секунду могут выполняться на узлах хранилища + вычислений. Например, приложения потоковой обработки могут разделять рабочие нагрузки, требующие больше памяти и вычислительных ресурсов (например, рабочие нагрузки поиска событий или аналитики), и масштабировать их соответствующим образом и независимо от тяжелых рабочих нагрузок операций ввода-вывода в секунду (например, сжатие и архивирование).

Надёжность

Система надежна, когда она может выдержать частичный отказ и восстановление без серьезного ухудшения качества обслуживания. Часть надежности системы включает в себя предсказуемость ее операций с точки зрения задержки, пропускной способности и соблюдения согласованного диапазона операций. Обычные подходы к обеспечению надежности системы включают следующее:
  • Настройка резервирования системы для поддержки прозрачного или минимального аварийного переключения.
  • Создание отказоустойчивости в случае внутренних ошибок или сбоев, вызванных вводом.
  • Четкое определение контрактов и целевых показателей задержки, пропускной способности и доступности.
  • Создание достаточных резервных мощностей для удовлетворения всплесков и органического роста нагрузки.
  • Гарантии качества обслуживания для обеспечения соблюдения ограничений скорости и изоляции клиентов/операций.
  • Реализация корректной деградации службы в сценариях перегрузки или катастрофического сбоя.
Ключевая вещь, которую следует помнить для создания надежных систем, — это обрабатывать потенциальные сбои четко определенным образом, на который зависимые системы могут реагировать. Точно так же, если система зависит от другой системы, которая может быть ненадежной, то она должна справляться с ненадежностью с помощью стратегий обеспечения надежности.

Поддерживаемость

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

Доступность

Если служба недоступна, возможно, она не существует. При проектировании систем следует учитывать, как система должна оставаться доступной, чтобы оставаться актуальной для клиентов и пользователей системы. Это означает:
  • Введение избыточности для обработки сбоев базовой системы.
  • Наличие сценариев резервного копирования и восстановления, а также руководств по эксплуатации для восстановления системы после жестких сбоев.
  • Удалите как можно больше единичных точек сбоев из системы.
  • Наряду с горизонтальной масштабируемостью используйте региональные реплики и настройте сети доставки контента (при необходимости), чтобы сделать ваши данные доступными.
  • Отслеживайте доступность вашей системы с точки зрения ваших клиентов, чтобы лучше понять, как ваша система обслуживает клиентов.

Безопасность

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

Современные шаблоны проектирования систем

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

Микросервисы

С появлением распределенных систем, которые сосредоточены на повышении надежности и масштабирования за счет резервирования, эффективности и производительности за счет горизонтального масштабирования, а также отказоустойчивости за счет разделения частей системы как независимо работающих сервисов, термин «микросервисы» приобрел популярность благодаря достижению следующего:
  • Привязка разработки, развертывания, эксплуатации и обслуживания независимых сервисов к командам, владеющим этими службами в рамках более крупной бизнес-операции. Мы можем сделать это, обслуживая внешних клиентов напрямую или косвенно через внутренних клиентов через API.
  • Позволяет микросервису независимо масштабироваться в соответствии с потребностями.
  • Предоставление услуг на основе четко определенного контракта позволяет реализации развиваться, чтобы оставаться автономной услугой или системой услуг.
Глядя на наши аспекты, микросервисы обладают привлекательными свойствами, что делает их хорошим образцом для подражания, если он применим к варианту использования:
  • Масштабируемость: микросервисы без состояния, как правило, предназначены для горизонтального масштабирования, а также могут извлечь выгоду из вертикального масштабирования. В случае микросервисов, развернутых в контейнерной среде оркестровки (например, кластерах Kubernetes), микросервисы могут даже работать на одних и тех же узлах, что обеспечивает более эффективное использование существующего оборудования и масштабирование в соответствии с требованиями доступной емкости. Одним из недостатков является сложность развертывания по мере увеличения масштаба и критичности микросервисов.
  • Надежность: микросервисы без состояния обычно размещаются за подсистемой балансировки нагрузки и географически распределены, чтобы избежать региональных сбоев, забирающих всю емкость системы. Одним из недостатков повышения надежности с помощью микросервисов без состояния является то, что система хранения данных, как правило, должна быть такой же или более надежной, чем реализация или развертывание микросервиса. Микросервисы с состоянием страдают от худшего из обоих подходов, где затраты на надежность обычно выражаются в виде избыточного выделения ресурсов для обработки потенциальных сбоев.
  • Удобство сопровождения: микросервисы, реализующие четко определенный и стабильный контракт, обслуживаемый через API, позволяют клиентам программировать на основе этого API, а реализация развивается независимо. Однако координация изменений в API включает в себя потенциально дорогостоящую миграцию клиентов и координацию между командами, что приводит к периоду, когда микросервис имеет несколько активно поддерживаемых версий до тех пор, пока последние клиенты не перейдут из старой реализации. Ситуация только ухудшается по мере того, как все больше клиентов начинают взаимодействовать с микросервисом.
  • Доступность: микросервисы обычно полагаются на среду развертывания и внешнюю инфраструктуру для удовлетворения требований клиентов к доступности. Недостатком этого является зависимость от конкретной инфраструктуры, на которой развертывается микросервис, для предоставления решения высокой доступности. Такие системы, как сервисные сетки и программные балансировщики нагрузки, становятся критически важными частями инфраструктуры, которые больше не контролируются реализацией. Это может быть хорошо, но также может быть постоянным источником обслуживания, поскольку эти системы также имеют циклы обновления и эксплуатационные расходы.
  • Безопасность: аутентификация, авторизация, управление идентификацией и управление учетными данными могут быть делегированы промежуточному ПО или с помощью внешних механизмов (например, удостоверений рабочей нагрузки в Kubernetes), где реализация микросервисов может быть сосредоточена на интеграции соответствующей бизнес-логики. Недостатком, как и доступность, является то, что эти внешние части решения становятся критически важными частями инфраструктуры, которые приносят свои собственные эксплуатационные расходы поверх реализации микросервиса.
Микросервисы — это отличный способ разбить большое приложение, где можно определить логические разделы, требующие собственных доменов масштабирования и надежности. Однако, когда вы начинаете с нуля, не лучше проектировать микросервисы с самого начала из-за риска разбить службы на слишком мелкие части. Затраты на обмен данными между микросервисами (как правило, в виде запросов HTTP или gRPC) значительны и должны быть понесены только в случае необходимости. Хороший способ определить, подходит ли функциональность для службы, — следовать таким практикам, как проектирование на основе предметной области или функциональная декомпозиция.

Бессерверные технологии

Как и в решениях на основе микросервисов, использование бессерверных реализаций дополнительно делегирует ключевые элементы функциональности обслуживания запросов базовой инфраструктуре. Если в микросервисах служба обслуживается постоянным процессом, бессерверные решения обычно реализуют только точку входа для обработки запроса к конечной точке (обычно URI через HTTP или gRPC). В бессерверных развертываниях фактические серверы не настраиваются, а среда развертывания запускает ресурсы по мере необходимости для обработки запросов по мере их поступления. Иногда эти ресурсы остаются в силе в течение некоторого времени, чтобы амортизировать затраты на их создание, но это должно быть деталью реализации. Давайте рассмотрим аспекты проектирования системы, чтобы увидеть, как складываются бессерверные решения:
  • Масштабируемость: Бессерверные решения так же горизонтально масштабируемы, как и микросервисы, если не больше, потому что они спроектированы так, чтобы иметь правильный размер по требованию. Недостатком этого подхода является необходимость большего контроля и полного делегирования функций масштабирования базовой бессерверной инфраструктуре.
  • Надежность: Надежность бессерверных технологий зависит от емкости горизонтального масштабирования и маршрутизации сетевого трафика. Это имеет те же недостатки, что и решение Microservices.
  • Удобство сопровождения: Бессерверные реализации более удобны в обслуживании, чем микросервисы, из-за акцента на бизнес-логике обработки запросов с минимальным шаблоном. Это имеет те же проблемы с эволюцией API, что и микросервисы.
  • Доступность: бессерверные системы доступны так же, как и среда, в которой они развернуты. Это имеет те же проблемы, когда базовая инфраструктура становится более важной, чем само решение.
  • Безопасность: Бессерверные реализации полностью зависят от конфигурации безопасности базовой инфраструктуры. Это имеет те же проблемы, когда базовая инфраструктура становится более важной, чем само решение.
Бессерверные решения, или функции как услуга, являются очень привлекательным способом создания прототипов и даже развертывания решений производственного уровня, сосредотачиваясь на бизнес-логике и ценности и позволяя базовой инфраструктуре управлять масштабируемостью, надежностью и доступностью службы. Это типичная отправная точка для получения решения с минимальной эксплуатационной нагрузкой, и для большинства прототипов это отличный способ доказать нашу гипотезу. Также типично то, что, как только эти решения достигают пределов масштабирования, затраты, связанные с их запуском, становятся достаточно высокими. Они превращаются в более оптимальные реализации микросервисов, настроенные на необходимый масштаб.

Событийно-ориентированные системы (Event-Driven)

Тем не менее, есть некоторые проблемные области, где обработка онлайн-транзакций не требуется, а микросервисы и бессерверные реализации не совсем соответствуют всем требованиям. Рассмотрим случаи, когда обработка транзакций может выполняться в фоновом режиме или при наличии ресурсов. Другой случай касается фоновой обработки, когда результаты не обязательно являются интерактивными. Системы, управляемые событиями, следуют схеме наличия источника событий и приемников событий, откуда происходят и отправляются события (сообщения) соответственно. Обработка происходит от подписчиков и издателей к этим источникам и приемникам соответственно. Примером событийно-управляемой системы является чат-бот, который может участвовать во многих беседах (источники событий и приемники) и обрабатывать сообщения по мере их поступления. Распределенные системы, управляемые событиями, могут иметь несколько параллельных обработчиков сообщений, ожидающих в одних и тех же источниках, что может привести к публикации слишком большого количества приемников, которые выступают в качестве источников для других обработчиков сообщений. Этот шаблон объединения процессоров через приемники и источники называется конвейером событий. Как правило, существует единая реализация приемников и источников, которая предоставляет интерфейс очереди сообщений и масштабируется в соответствии со спросом на сообщения, поступающие через систему. Многие системы управления распределенными очередями также могут эффективно использовать диагональное масштабирование, например Apache Kafka, RabbitMQ и т. д. Давайте рассмотрим распределенные системы, управляемые событиями, с точки зрения наших пяти аспектов:
  • Масштабируемость: как реализация брокера сообщений/событий, так и обработчики сообщений могут масштабироваться независимо друг от друга. Некоторые недостатки возникают, когда обрабатывается слишком много сообщений/событий, и спрос на брокера событий растет далеко за пределы пропускной способности, доступной в системе.
  • Надежность: Хорошие реализации брокера сообщений обеспечивают высокий уровень надежности, и рекомендуется не создавать собственную реализацию брокера сообщений. Недостатком является зависимость от решения, которое отвечает требованиям надежности решения (например, обработка финансовых транзакций сильно отличается от обработки маршрутизации обмена мгновенными сообщениями в чатах).
  • Удобство сопровождения: Если вы используете гибкий формат обмена сообщениями, такой как буферы протоколов, вполне вероятно развивать авторов и читателей сообщений, используя один и тот же язык описания данных. Это по-прежнему требует координации, но не такой обременительной, как развивающиеся контракты API в системах обработки транзакций в реальном времени (как в микросервисах и бессерверных реализациях).
  • Доступность: cистемы, управляемые событиями, обычно легче сделать доступными, тем более что они, как правило, не являются интерактивными приложениями. Стоимость доступности может быть связана с устаревшими сообщениями и неограниченными задержками обработки очередей.
  • Безопасность: системы, управляемые событиями, должны управлять доступностью данных независимо от учетных данных. Обеспечение того, чтобы только определенные службы или обработчики сообщений могли получить доступ к определенным очередям сообщений или журналам, становится постоянной работой, поскольку через систему проходят более разнообразные данные.

Итоги

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

Чистая архитектура в Node.js

год назад·10 мин. на чтение

Чистая архитектура (Clean Architecture) — это концепция разработки программного обеспечения, которая фокусируется на создании модульного и поддерживаемого кода. Архитектура позволяет разработчику создавать кодовую базу, которую легко понять, протестировать и расширить.

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

Выявление и решение проблем

При разработке приложений Node.js мы часто сталкиваемся с некоторыми проблемами, такими как дублирование кода, неорганизованная кодовая база и тесная связь (tight coupling). В следующем разделе мы используем простой пример приложения Node.js, которое извлекает данные из базы данных и возвращает их в качестве ответа JSON. Чистая архитектура предлагает решения этих проблем, делая упор на следующие принципы:

Разделение ответственности (Separation of Concerns, SoC)

Фундаментальный принцип разработки программного обеспечения, который подчеркивает важность разделения системы на отдельные модули или компоненты, каждый из которых несет определенную и независимую ответственность. В Node.js SoC часто реализуется с использованием модульной архитектуры, где каждый модуль отвечает за одну задачу или функциональность. Вот пример того, как разделение ответственности может быть применено к этому коду:
// index.js - Плохой код!

const express = require('express')
const app = express()
const database = require('./database')

app.get('/users', async (req, res) => {
  try {
    const users = await database.getUsers()
    res.json(users)
  } catch (error) {
    res.status(500).send('Internal Server Error')
  }
})

app.listen(3000, () => {
  console.log('Server is listening on port 3000')
})
В этом коде мы смешали задачи маршрутизации, извлечения данных и обработки ошибок в одном файле. Это может затруднить обслуживание и масштабирование кода по мере роста приложения.
Вот как мы можем применить разделение ответственности к этому коду:
// index.js

const express = require('express')
const app = express()
const usersRouter = require('./routes/users')

app.use('/users', usersRouter)

app.listen(3000, () => {
  console.log('Server is listening on port 3000')
})
// routes/users.js

const express = require('express')
const router = express.Router()
const usersController = require('../controllers/users')

router.get('/', usersController.getUsers)

module.exports = router
// controllers/users.js

const database = require('../database')

async function getUsers(req, res) {
  try {
    const users = await database.getUsers()
    res.json(users)
  } catch (error) {
    res.status(500).send('Internal Server Error')
  }
}

module.exports = {
  getUsers,
}
В этом переработанном коде мы разделили задачи маршрутизации, контроллера и извлечения данных на три отдельных файла. Файл index.js отвечает за создание приложения Express и регистрацию маршрутов, файл routes/users.js отвечает за обработку маршрута /users и делегирование запроса usersController, а файл controllers/users.js отвечает за извлечение данных из базы данных и возврат ответа клиенту. Разделив эти задачи, мы можем достичь лучшей модульности и удобства сопровождения кода. Например, если мы хотим добавить больше маршрутов, мы можем создать новый файл в routes и зарегистрировать его в index.js без изменения существующего кода. Аналогичным образом, если мы хотим изменить способ извлечения данных из базы данных, мы можем изменить database.js файл без изменения маршрута или кода контроллера.

Инверсия зависимостей (Dependency Inversion, DI)

В Clean Architecture зависимости инвертируются, что означает, что модули более высокого уровня должны зависеть от модулей более низкого уровня. Это гарантирует, что бизнес-логика не будет связана с деталями инфраструктуры. Вот пример того, как инверсия зависимостей может быть применена к этому коду:
// index.js - Плохой код!

const express = require('express')
const app = express()

const usersController = require('./controllers/users')
app.get('/users', async (req, res) => {
  try {
    const users = await usersController.getUsers()
    res.json(users)
  } catch (error) {
    res.status(500).send('Internal Server Error')
  }
})

app.listen(3000, () => {
  console.log('Server is listening on port 3000')
})
// controllers/users.js

const database = require('../database')
async function getUsers() {
  try {
    const users = await database.getUsers()
    return users
  } catch (error) {
    throw new Error('Error retrieving users')
  }
}

module.exports = {
  getUsers,
}
В этом коде index.js напрямую зависит от модуля usersController, который в свою очередь напрямую зависит от модуля database. Это нарушает принцип инверсии зависимостей, поскольку высокоуровневые модули не должны зависеть от низкоуровневых модулей.
Вот как мы можем применить инверсию зависимостей к этому коду:
// index.js

const express = require('express')
const app = express()
const usersController = require('./controllers/users')
const database = require('./database')

app.get('/users', async (req, res) => {
  try {
    const users = await usersController.getUsers(database)
    res.json(users)
  } catch (error) {
    res.status(500).send('Internal Server Error')
  }
})

app.listen(3000, () => {
  console.log('Server is listening on port 3000')
})
// controllers/users.js

async function getUsers(database) {
  try {
    const users = await database.getUsers()
    return users
  } catch (error) {
    throw new Error('Error retrieving users')
  }
}

module.exports = {
  getUsers,
}
В этом переработанном коде мы применили Dependency Inversion, передав модуль database в качестве параметра функции getUsers в модуле usersController. Таким образом, высокоуровневый модуль index.js не зависит напрямую от низкоуровневого модуля database, но оба зависят от абстракции функции getUsers. Применяя инверсию зависимостей, мы можем добиться большей модульности, гибкости и тестируемости кода. Например, если мы хотим переключиться на другую реализацию базы данных, мы можем создать новый модуль, реализующий функцию getUsers, и передать ее в качестве getUsers в модуле usersController без изменения существующего кода. Точно так же мы можем легко имитировать модуль database для целей модульного тестирования.

Принцип единой ответственности (Single Responsibility Principle, SRP)

Каждый модуль или функция должны нести единую ответственность. Это помогает в создании кодовой базы, которую легко понять и поддерживать. Вот пример в Node.js который иллюстрирует принцип SRP:
// user.js - Плохой код!

class User {
  constructor(name, email, password) {
    this.name = name;
    this.email = email;
    this.password = password;
  }

  saveToDatabase() {
    await database.saveUser(user)
    .then(() => {
      res.status(200).send()
    })
    .catch(err => {
      res.status(400).send('Email Error')
    });
  }

  sendWelcomeEmail() {
    await mailService.send(user, 'Welcome')
    .then(() => {
      res.status(200).send()
    })
    .catch(err => {
        res.status(400).send('Email Error')
    });
  }
}
В этом примере у нас есть класс User, который имеет две обязанности:
  1. Сохранение пользовательских данных в базе данных
  2. Отправка приветственного электронного письма пользователю
Это нарушает принцип SRP, поскольку класс User имеет несколько причин для изменения. Например, если мы решим изменить способ сохранения пользовательских данных в базе данных, нам также придется изменить класс User, даже если это не связано с отправкой приветственного электронного письма.
Чтобы следовать принципу SRP, мы можем разделить эти обязанности на отдельные классы:
class User {
  constructor(name, email, password) {
    this.name = name;
    this.email = email;
    this.password = password;
  }
}

class UserRepository {
  saveToDatabase(user) {
    await database.saveUser(user)
    .then(() => {
      res.status(200).send()
    })
    .catch(err => {
      res.status(400).send('Email Error')
    });
  }
}

class EmailService {
  sendWelcomeEmail(user) {
      await mailService.send(user, 'Welcome')
      .then(() => {
        res.status(200).send()
      })
      .catch(err => {
        res.status(400).send('Email Error')
      });
    }
  }
}
Теперь у нас есть три класса, каждый из которых несет единую ответственность:
  1. User: отвечает за представление пользователя.
  2. UserRepository: отвечает за сохранение пользовательских данных в базе данных.
  3. EmailService: отвечает за отправку приветственного электронного письма пользователю.
Разделив обязанности, мы сделали наш код более модульным и простым в обслуживании. Если нам нужно изменить способ сохранения пользовательских данных в базе данных, нам нужно только изменить класс UserRepository. Класс User и класс EmailService остаются неизменными.

Концепции и детальное проектирование

Чистая архитектура в Node.js основана на принципах чистой архитектуры, введенных Робертом С. Мартином (он же дядя Боб). В нем подчеркивается разделение ответственности, разъединение зависимостей и модульность. Цель состоит в том, чтобы создать кодовую базу, которую легко понять, протестировать и поддерживать. Основная идея Clean Architecture заключается в разделении приложения на разные слои, где каждый уровень несет определенную ответственность. Слои взаимодействуют друг с другом через четко определенные интерфейсы. Это позволяет легко модифицировать и тестировать приложение, не затрагивая другие части кодовой базы. Node.js — это популярная среда выполнения для создания веб-приложений. Он имеет обширную экосистему библиотек и фреймворков, которые можно использовать для реализации Clean Architecture. Вот некоторые из ключевых концепций чистой архитектуры в Node.js:

Уровень инфраструктуры (Infrastructure Layer)

Уровень инфраструктуры отвечает за обработку внешних зависимостей, таких как базы данных, API или файловая система. Он должен быть отделен от уровня домена, чтобы обеспечить легкое тестирование и модификацию. Уровень инфраструктуры должен реализовывать интерфейсы, определенные уровнем домена. В Node.js уровень инфраструктуры может быть реализован с помощью пакетов или модулей. Например, можно использовать популярный пакет Knex.js для обработки запросов к базе данных. Уровень инфраструктуры должен быть спроектирован так, чтобы быть подключаемым, что позволяет легко заменять внешние зависимости. Вот пример модуля инфраструктуры, реализующего адаптер базы данных:
const knex = require('knex');

class UserDatabase {
  constructor(config) {
    this.db = knex(config);
  }
  
  async getById(id) {
    const data = await this.db('users').where({ id }).first();
    return data ? User.create(data) : null;
  }
  
  async save(user) {
    const data = User.toData(user);
    const { id } = user;
    
    if (id) {
      await this.db('users').where({ id }).update(data);
    } else {
      const [newId] = await this.db('users').insert(data);
      user.id = newId;
    }
  }
}
Этот модуль предоставляет методы для получения пользователя по идентификатору и сохранения пользователя в базе данных с помощью библиотеки Knex.js.

Уровень представления (Presentation Layer)

Уровень представления отвечает за отображение выходных данных приложения для пользователя и обработку вводимых пользователем данных. Он должен быть отделен от прикладного уровня и уровня инфраструктуры. Уровень представления может быть реализован с помощью веб-фреймворков, таких как Express.js или Hapi.js. В Node.js уровень представления может быть реализован с помощью веб-фреймворков или модулей. Веб-фреймворки предоставляют мощный и гибкий способ реализации уровня представления и размещения всей логики вместе. Вот пример модуля презентации, реализующего REST API с помощью веб-платформы Express.js:
const express = require('express');
const bodyParser = require('body-parser');
const UserService = require('./services/user-service');
const UserDatabase = require('./infra/user-database');

const app = express();

app.use(bodyParser.json());

const userDatabase = new UserDatabase(config);
const userService = new UserService(userDatabase);

app.get('/users/:id', async (req, res) => {
  const { id } = req.params;
  try {
    const user = await userService.getUserById(id);
    res.json(user);
  } catch (error) {
    res.status(404).json({ error: error.message });
  }
});

app.put('/users/:id', async (req, res) => {
  const { id } = req.params;
  const { userData } = req.body;
  try {
    let user = await userService.getUserById(id);
    user = User.create({ ...user, ...userData });
    await userService.saveUser(user);
    res.json(user);
  } catch (error) {
    res.status(404).json({ error: error.message });
  }
});
Этот модуль создает приложение Express.js, настраивает пользовательскую службу и базу данных, а также предоставляет конечные точки REST API для получения и обновления пользовательских данных.

Прикладной уровень (Application Layer)

Прикладной уровень отвечает за оркестрацию взаимодействия между доменным уровнем и уровнем инфраструктуры. Он содержит варианты использования приложения, которые представляют взаимодействия между пользователем и системой. Прикладной уровень должен быть отделен от уровня домена и уровня инфраструктуры. В Node.js прикладной уровень может быть реализован с помощью классов или модулей. Классы обеспечивают четкое разделение ответственности и инкапсуляцию. Модули обеспечивают более простой подход к реализации прикладного уровня. Вот пример класса приложения, представляющего пользовательскую службу:
class UserService {
  constructor(userDatabase) {
    this.userDatabase = userDatabase;
  }
  
  async getUserById(id) {
    const user = await this.userDatabase.getById(id);
    if (!user) {
      throw new Error(`User not found with ID ${id}`);
    }
    return user;
  }
  
  async saveUser(user) {
    await this.userDatabase.save(user);
  }
}
Этот класс предоставляет методы для получения пользователя по идентификатору и сохранения пользователя с помощью модуля инфраструктуры UserDatabase.

Уровень домена (Domain (Enterprise) Layer)

Доменный уровень является сердцем приложения, содержащим бизнес-логику и правила. Он должен быть независим от каких-либо внешних библиотек или фреймворков, что упрощает его тестирование и изменение. Доменный уровень является наиболее важной частью приложения, и любые изменения должны вноситься с большой осторожностью. В Node.js, уровень домена может быть реализован с помощью классов или модулей. Классы обеспечивают четкое разделение ответственности, инкапсуляцию и возможность повторного использования. Модули, с другой стороны, обеспечивают более простой подход к реализации доменного уровня. Вот пример класса домена, представляющего сущность пользователя:
class User {
  constructor(id, name, email) {
    this.id = id;
    this.name = name;
    this.email = email;
  }
  
  changeName(name) {
    this.name = name;
  }
  
  changeEmail(email) {
    this.email = email;
  }
  
  static create(data) {
    const { id, name, email } = data;
    return new User(id, name, email);
  }
  
  static toData(user) {
    const { id, name, email } = user;
    return { id, name, email };
  }
}
Этот класс инкапсулирует пользовательские данные и предоставляет методы для изменения имени и адреса электронной почты пользователя.

Использование сторонних npm пакетов

Использование сторонних пакетов — отличный способ повысить чистоту кода. Существует множество пакетов, которые могут помочь вам организовать кодовую базу и сделать ее более модульной. Например, можно использовать пакет, например Express.js для обработки маршрутизации и промежуточного ПО. Вы также можете использовать пакет, такой как Knex.js для обработки запросов к базе данных. Использование этих пакетов может помочь уменьшить дублирование кода и сделать базу кода более организованной. Вот еще несколько примеров использования сторонних пакетов:

Lodash

Lodash — это служебная библиотека, предоставляющая широкий спектр функций для работы с массивами, объектами и другими структурами данных. Используя Lodash, можно избежать написания повторяющегося кода для таких задач, как фильтрация, сортировка и преобразование данных. Например, рассмотрим следующий код для фильтрации массива пользователей по возрасту:
const users = [
  { name: 'Alice', age: 25 },
  { name: 'Bob', age: 30 },
  { name: 'Charlie', age: 35 },
];

const filteredUsers = users.filter(user => user.age >= 30);
Используя Lodash, вы можете вместо этого написать следующий код:
const _ = require('lodash');

const users = [
  { name: 'Alice', age: 25 },
  { name: 'Bob', age: 30 },
  { name: 'Charlie', age: 35 },
];

const filteredUsers = _.filter(users, user => user.age >= 30);
Этот код более лаконичный и легкий для чтения, а использование функции filter от Lodash дает понять, что делает код.

Moment.js или date-fns

Moment.js — это библиотека для синтаксического анализа, манипулирования и форматирования даты и времени. Используя Moment.js, можно избежать написания сложного кода манипуляции с датой и снизить вероятность ошибок. Например, рассмотрим следующий код для форматирования даты в виде строки:
const date = new Date();
const formattedDate = `${date.getFullYear()}-${date.getMonth() + 1}-${date.getDate()}`;
Используя Moment.js, вы можете вместо этого написать следующий код:
const moment = require('moment');
const date = new Date();
const formattedDate = moment(date).format('YYYY-MM-DD');
Этот код легче читать и поддерживать, а использование функции format от Moment.js дает понять, что делает код.

Winston

Winston — это библиотека логирования (журналирования), которая предоставляет множество функций для ведения журнала сообщений, включая различные уровни логов и настраиваемое форматирование. Используя Winston, вы можете избежать написания пользовательского кода ведения журнала и убедиться, что ваши журналы согласованы и легко читаются. Например, рассмотрим следующий код для регистрации сообщения:
console.log(`[${new Date().toISOString()}] INFO: User logged in`);
Используя Winston, вы можете вместо этого написать следующий код
const winston = require('winston');

const logger = winston.createLogger({
  level: 'info',
  format: winston.format.combine(
    winston.format.timestamp(),
    winston.format.printf(info => `[${info.timestamp}] ${info.level}: ${info.message}`)
  ),
  transports: [
    new winston.transports.Console(),
    new winston.transports.File({ filename: 'app.log' }),
  ],
});
logger.info('User logged in');
Этот код более настраиваемый и легко читаемый, а использование Winston дает понять, что делает код.

Итоги

Чистая архитектура — это мощная концепция, которая может помочь вам создать модульный и поддерживаемый код в проектах Node.js. Следуя принципам чистой архитектуры, можно создать кодовую базу, которую легко понять, протестировать и расширить. Можно также использовать сторонние пакеты и различные структуры папок для повышения чистоты кода. Реализация Clean Architecture в проектах Node.js может помочь вам избежать распространенных ошибок, таких как дублирование кода, неорганизованная кодовая база и тесная связь.