Введение в проектирование систем (System Design): как стать Senior программистом

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

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

Что такое проектирование систем (system design)?

Проектирование системы определяет архитектуру, компоненты, интерфейсы и данные для системы, удовлетворяющей заданным требованиям. Оно включает в себя идентификацию и определение функциональных и нефункциональных требований к системе, а также ограничений и компромиссов, которые должны быть сделаны в процессе разработки. Цель проектирования системы — создать эффективную, надежную и простую в обслуживании систему, отвечающую потребностям пользователей и заинтересованных сторон. Этот процесс обычно включает в себя комбинацию подходов «сверху вниз» и «снизу вверх» с упором на модульность, масштабируемость и возможность повторного использования. Надлежащий дизайн системы учитывает местоположение пользователей, используемые технологии и контент, совместно используемый в сети, в которой он находится.
Системный дизайн в программном обеспечении важен по нескольким причинам.
  • Это помогает гарантировать, что конечный продукт соответствует потребностям пользователей и заинтересованных сторон. Четко определяя требования и ограничения системы, разработчики могут гарантировать, что программное обеспечение будет удобным в использовании, эффективным и действенным.
  • Дизайн системы позволяет создавать масштабируемую и модульную архитектуру. Это упрощает добавление новых функций или внесение изменений в систему в будущем без нарушения существующей функциональности. Это также позволяет повторно использовать код и компоненты в разных проектах, экономя время и ресурсы.
  • Дизайн системы играет решающую роль в “ремонтопригодности” программного обеспечения. Хорошо спроектированную систему легче понять, протестировать и отладить, что снижает вероятность появления новых ошибок и упрощает исправление существующих.
  • Системный дизайн необходим для создания эффективного и высокопроизводительного программного обеспечения. Внимательно рассматривая требования к производительности и масштабируемости в процессе проектирования, разработчики могут гарантировать, что конечный продукт будет соответствовать требованиям пользователей и не будет создавать узких мест или сбоев при большой нагрузке.

Вопросы, которые необходимо задать перед проектированием программной системы

Важно отметить, что это всего лишь несколько примеров вопросов, которые инженер-программист должен учитывать при создании крупной системы. Вопросы будут зависеть от требований системы и домена, в котором она работает.
  • Каковы цели и требования системы?
  • Каковы ожидаемые модели трафика и использования системы?
  • Как система должна обрабатывать сбои и ошибки?
  • Как система должна обеспечивать масштабируемость и производительность?
  • Как система должна обеспечивать безопасность и контроль доступа?
  • Как система должна обеспечивать хранение и поиск данных?
  • Как система должна обеспечивать согласованность и целостность данных?
  • Как система должна обрабатывать резервные копии и восстановление данных?
  • Как система должна обрабатывать мониторинг и ведение логов?
  • Как система должна обрабатывать обновления и обслуживание?
  • Как система должна обеспечивать интеграцию с другими системами и службами?
  • Как система должна обеспечивать соответствие нормативным требованиям и конфиденциальность данных?
  • Как система должна обеспечивать аварийное восстановление и обеспечение непрерывности бизнеса?
  • Как система должна обрабатывать пользовательский опыт и удобство использования?
Основная цель этой статьи — помочь разработчикам понять концепции проектирования систем. Это не учебник, а скорее обзор этой темы. Теперь давайте погрузимся глубже.

Балансировщики нагрузки (Load Balancers)

Балансировщик нагрузки — это устройство или служба, распределяющая сетевой трафик или трафик приложений между несколькими серверами. Основная цель балансировщика нагрузки — повысить доступность и масштабируемость приложений за счет равномерного распределения рабочей нагрузки между несколькими серверами. Это гарантирует, что ни один сервер не станет узким местом и что система сможет обрабатывать большой объем трафика. Подумайте о попытке опорожнить большой резервуар для воды. Балансировщик нагрузки помогает опорожнить резервуар для воды, добавляя дополнительные отверстия в нижней части, чтобы увеличить поток воды, чтобы поступающая вода не вытекала из резервуара. Балансировщики нагрузки используют различные алгоритмы для определения того, как распределять трафик, например циклический (round-robin), когда запросы отправляются на каждый сервер по очереди, или метод наименьшего количества подключений, когда запросы отправляются на сервер с наименьшим числом активных подключений. Балансировщики нагрузки также могут отслеживать состояние каждого сервера, и если сервер становится недоступным, балансировщик нагрузки перенаправляет трафик на другие доступные серверы.

Балансировщики нагрузки DNS

Балансировка нагрузки DNS — еще один популярный метод распределения сетевого трафика между несколькими серверами с использованием системы доменных имен (DNS). Он настраивает различные IP-адреса для одного доменного имени. Затем он использует DNS-сервер для распределения входящего трафика на один из IP-адресов на основе алгоритма балансировки нагрузки.

Балансировка нагрузки по географическому принципу

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

Кэширование (Caching)

Кэширование — это метод, используемый при проектировании системы для повышения производительности и масштабируемости системы путем сохранения часто используемых данных во временном хранилище, известном как кэш. Есть несколько преимуществ кэширования при проектировании системы:
  • Уменьшенная задержка: локальное кэширование данных может значительно сократить время, необходимое для доступа к данным, поскольку устраняет необходимость извлечения данных из удаленного местоположения. Это может привести к более быстрому времени отклика для конечного пользователя.
  • Повышенная пропускная способность. Кэширование также может увеличить количество запросов, которые система может обрабатывать одновременно, поскольку оно уменьшает количество запросов, которые необходимо отправить на внутренний сервер. Это поможет предотвратить перегрузку системы в периоды высокой нагрузки.
  • Снижение нагрузки на бэкэнд серверы. Кэширование также может снизить нагрузку на серверы за счет уменьшения количества запросов, которые им необходимо обрабатывать. Это может улучшить общую производительность и масштабируемость системы.
  • Автономный доступ: локальное кэширование данных также может обеспечить автономный доступ к данным, даже если сервер недоступен. Это может быть особенно полезно для мобильных приложений или приложений IoT, где подключение гарантируется лишь иногда.
  • Экономичность: кэширование может снизить затраты, связанные с масштабированием системы, за счет снижения нагрузки на серверы и потребности в дополнительном оборудовании или пропускной способности сети.

Кэширование в памяти (In memory caching)

Кэширование в памяти — это тип кэширования, при котором данные хранятся в основной памяти системы (ОЗУ), а не на диске. Это обеспечивает более быстрый доступ к кэшированным данным, поскольку к данным, хранящимся в памяти, можно получить доступ гораздо быстрее, чем к хранящимся на диске. Основным преимуществом кэширования в памяти является его высокая производительность. Поскольку данные хранятся в оперативной памяти, к ним можно получить доступ намного быстрее, чем к данным, хранящимся на диске. Это может значительно улучшить время отклика системы, особенно для часто используемых данных. Еще одним преимуществом кэширования в памяти является то, что оно не требует дисковых операций ввода-вывода, которые могут быть медленными и ресурсоемкими. Это может помочь снизить нагрузку на систему и повысить общую производительность. Кэширование в памяти можно реализовать с помощью различных инструментов и библиотек, таких как Memcached, Redis и Hazelcast. Эти инструменты предоставляют простой интерфейс для хранения и извлечения данных из памяти, а также их можно использовать для реализации распределенного кэширования на нескольких серверах. Стоит отметить, что кэширование в памяти имеет ограничения; в основном, размер доступной оперативной памяти для данных, которые могут быть сохранены в памяти, ограничен. Кроме того, данные, хранящиеся в памяти, являются энергозависимыми, что означает, что они будут потеряны в случае перезагрузки или сбоя системы.

CDN

Сети доставки контента (CDN) — это распределенная сеть серверов, которые доставляют контент, такой как веб-страницы, изображения и видео, пользователям в зависимости от их географического положения. CDN могут помочь с кэшированием программного обеспечения, предоставляя способ кэширования и распространения контента ближе к конечным пользователям, уменьшая задержку и повышая производительность системы. Когда пользователь запрашивает контент с веб-сайта или приложения, запрос сначала отправляется на ближайший сервер CDN, «пограничный сервер» (edge server). Пограничный сервер проверяет свой кэш, чтобы узнать, хранится ли запрошенный контент локально. Если контент найден на складе, он сразу же доставляется пользователю. Если контент не найден в кэше, пограничный сервер извлекает его с исходного сервера и локально кэширует для будущих запросов. Кэшируя контент локально на пограничных серверах, CDN могут снизить нагрузку на исходный сервер и уменьшить задержку для конечного пользователя. Это может быть особенно полезно для веб-сайтов и приложений, которые обслуживают множество пользователей, или для пользователей, находящихся далеко от исходного сервера. Кроме того, CDN также могут помочь повысить безопасность и доступность системы, обеспечивая защиту от DDoS-атак и балансировку нагрузки.

Базы данных

Проектирование схемы базы данных

Проектирование схемы базы данных — это создание схемы базы данных, которая определяет структуру данных и отношения между различными элементами данных. Сюда входит определение таблиц, полей, ключей, индексов и ограничений, составляющих базу данных. Хороший дизайн схемы базы данных необходим для обеспечения эффективности, гибкости и простоты обслуживания базы данных. Он должен быть основан на четком понимании требований и целей системы, и он должен быть масштабируемым, безопасным и надежным. Процесс проектирования схемы базы данных обычно включает несколько этапов, в том числе:
  1. Определение сущностей и их отношений
  2. Определение атрибутов и типов данных для каждой сущности
  3. Определение ключей и ограничений для каждой таблицы
  4. Создание индексов для повышения производительности запросов
  5. Нормализация базы данных для устранения избыточности и улучшения целостности данных
  6. Тестирование и документирование схемы для простоты использования
Также важно отметить, что проектирование — это непрерывный процесс, поскольку база данных должна меняться и адаптироваться с течением времени.

Индексы базы данных

Индекс базы данных — это структура данных, которая повышает скорость операций извлечения данных из таблицы базы данных. Это позволяет системе управления базами данных быстро находить и извлекать определенные строки данных из таблицы. Индексы создаются для одного или нескольких столбцов таблицы, а данные в этих столбцах хранятся особым образом (например, в B-дереве или хэш-таблице) для оптимизации производительности поиска. Что касается дизайна системы, индексы могут значительно повысить производительность приложения, управляемого базой данных, за счет сокращения времени, необходимого для извлечения данных из таблицы. Это может быть особенно важно в больших и сложных системах, где необходимо извлечь много данных или где к данным часто обращается несколько пользователей. Использование индексов также может снизить нагрузку на сервер базы данных, так как серверу не нужно сканировать всю таблицу, чтобы найти нужные данные. Важно отметить, что создание индексов также может иметь негативные последствия, такие как увеличение дискового пространства и затрат на обновление, поэтому при создании индексов важно быть избирательным и стратегическим. Всегда рекомендуется тестировать производительность вашей системы с индексами и без них, отслеживать влияние индексов на вашу систему и вносить соответствующие коррективы.

Разделение базы данных (шардирование, sharding)

Разделение базы данных — это метод, используемый для горизонтального разделения большой базы данных на более мелкие, более управляемые части, называемые шардами (shards). Каждый шард (сегмент) представляет собой отдельное независимое хранилище данных, содержащее подмножество данных из исходной базы данных. Данные в каждом шарде обычно организованы по некоторому ключу, например идентификатору пользователя, чтобы гарантировать, что все данные для конкретного пользователя находятся в одном шарде. Разделение может быть полезно в ряде различных сценариев, например, когда база данных стала слишком большой для эффективного управления одним сервером или когда большой объем запросов на чтение или запись вызывает проблемы с производительностью. Распределяя данные по нескольким серверам, шардирование может улучшить масштабируемость и производительность приложения, управляемого базой данных. Для реализации шардирования можно использовать несколько методов, например:
  • Шардирование на основе диапазона: данные разделяются на основе диапазона значений, например диапазона идентификаторов пользователей,
  • Разделение на основе хэша: данные разделяются на основе хеш-функции, применяемой к значению ключа, например идентификатору пользователя,
  • Разбиение на основе списка: данные разделяются на основе предопределенного списка значений, например страны или региона.
Важно отметить, что для шардирования требуется ключ шарда, который представляет собой поле, используемое для определения того, какому шарду принадлежит конкретная запись. Кроме того, важно учитывать, что шардирование усложняет систему, поэтому его следует рассматривать как крайнюю меру, когда другие решения, такие как индексирование, кэширование и оптимизация запросов, исчерпаны.

Дизайн API

Проектирование API (Application Programming Interface) включает в себя планирование и создание набора интерфейсов, протоколов и инструментов для создания программного обеспечения и приложений. Цель разработки API — предоставить согласованный и эффективный способ взаимодействия и обмена данными для различных программных систем. Обычно это включает в себя определение методов, входных и выходных данных и других спецификаций для API, а также тестирование и документирование API для простоты использования.

Репликации master-slave

В настройке репликации master-slave один сервер базы данных (master) назначается основным источником данных, а один или несколько других серверов (slave) настраиваются для репликации данных с master’а. Master-сервер постоянно обновляет свои данные и делает эти изменения доступными для slave-серверов, которые затем копируют и применяют эти изменения в своих собственных базах данных. Этот тип репликации используется для обеспечения избыточности и высокой доступности, поскольку slave-сервера могут использоваться для обработки запросов на чтение и обеспечения аварийного переключения в случае выхода из строя master’а. Его также можно использовать для масштабирования рабочих нагрузок с большим объемом операций чтения. В репликации master-slave master-сервер отвечает за обработку всех операций записи, а slave-серверы только реплицируют данные и не могут быть записаны. Это позволяет master-серверу сосредоточиться на обработке операций записи, в то время как slave-серверы обрабатывают запросы только на чтение, что может помочь повысить производительность. Существует несколько различных типов master-slave репликации, например репликация на основе операторов, репликация на основе строк или смешанная репликация, каждая из которых имеет свои преимущества и недостатки, а также различные методы репликации, такие как асинхронная и полусинхронная репликация. Важно отметить, что репликация может привести к несогласованности данных, и важно спроектировать систему таким образом, чтобы свести их к минимуму, а также иметь стратегию обработки сбоев репликации.

Чистая архитектура в 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 может помочь вам избежать распространенных ошибок, таких как дублирование кода, неорганизованная кодовая база и тесная связь.