Как проектировать приложение NestJS / GraphQL на основе предметной области: Часть 1 — Древовидная структура и запрос | Олдрик Либонис | Технология Муццо | Январь 2023 г.

Когда мы начали разрабатывать внутреннюю архитектуру веб-приложения Muzzo, мы быстро наткнулись на вопрос на миллион долларов:

Как мы можем максимизировать масштабируемость большого API в стартовой среде, которая требует много гибкости?

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

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

В этом первом опусе моя цель — показать вам, как реализовать простой запрос в ДДД мода.

Отражение моего опыта в Муццоя решил использовать NestJS и Машинопись в сочетании с ГрафQL поддержать мою демонстрацию. Я настоятельно рекомендую вам ознакомиться с этими технологиями, прежде чем продолжить чтение. 🤓

Наконец я использовал ТипORM как его интеграция с NestJS нестандартно.

Предпосылки

• TypeScript: базовое понимание интерфейса и набора текста
• NestJS: хорошее понимание внедрения зависимостей
• GraphQL: базовое понимание схемы и типов

Прежде всего, давайте кратко подытожим Дизайн, управляемый доменом и какой цели он служит. ДДД представляет собой подборку 20-летнего опыта, преобразованного Эриком Эвансом в передовой опыт. Что он теоретизировал в своей книге Дизайн, ориентированный на предметную область, устранение сложности в основе программного обеспечения (изд. 2003 г.), также называемый Синяя книга.

Требуется брезгливость, чтобы написать код, который не только делает правильные вещи, но и говорит правильные вещи. (Эрик Эванс, Domain-Driven Design: решение сложных задач в основе программного обеспечения)

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

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

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

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

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

Давайте теперь посмотрим, как этот принцип применим к современному приложению.

В целях следующей демонстрации я попрошу вас поставить себя на место Тренер покемонов. Скажем, вам нужно проконсультироваться со своим покедексом, чтобы получить данные о вашем последнем улове покемонов. Так получилось, что покедекс потребляет NestJS / ГрафQL API.

Древовидная структура проекта

Прежде чем углубляться в то, как организовать ГрафQL запрос в течение NestJS рамки в ДДД моды, давайте поговорим о самом ключевом аспекте такой архитектуры: ✨ Древовидная структура ✨

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

Следуя совету Мартина Фаулера, мы решили разделить наш код на ограниченные контексты и ЗАТЕМ на 4 слоя (домен, приложение, инфраструктура, представление), а не наоборот.

pokedex-api/
├─ src/
│  ├─ bounded-contexts/
│  │  ├─ pokémon-battle/
│  │  ├─ pokémon-catching/
│  │  ├─ pokémon-training/
│  │  │  ├─ application/
│  │  │  ├─ domain/
│  │  │  ├─ infrastructure/
│  │  │  │  ├─ gql-mappers/
│  │  │  │  ├─ repositories/
│  │  │  │  │  ├─ domain/
│  │  │  │  │  ├─ presentation/
│  │  │  │  │  │  ├─ pokémon.presentation.sql-repository.ts
│  │  │  ├─ presentation/
│  │  │  │  ├─ repositories/
│  │  │  │  │  ├─ pokémon.presentation.repository.ts
│  │  │  │  ├─ resolvers/
│  │  │  │  │  ├─ queries/
│  │  │  │  │  │  ├─ pokémon.resolver.ts
│  │  │  │  │  ├─ mutations/
│  │  │  ├─ pokémon-training.module.ts
│  ├─ shared-kernel/
│  │  ├─ application/
│  │  ├─ domain/
│  │  ├─ presentation/
│  │  │  ├─ dtos/
│  │  │  │  ├─ request/
│  │  │  │  ├─ response/
│  │  │  │  │  ├─ pokémon-gql-model.ts
│  ├─ app.module.ts
│  ├─ main.ts
├─ nest-cli.json
├─ package.json
├─ tsconfig.json
├─ .eslintrc.js

В следующих статьях я подробно расскажу о домене и содержании файлов мутаций.

Контроллер и объект передачи данных

Наш API получает входящий запрос GraphQL pokémon который возвращает покемона по его идентификатору. Его форма определяется ПокемонGQLМодель. Мы сосредоточимся на нем позже.

Как ГрафQL отвечает за проверку и выполнение запроса через соответствующий резольвер который берет на себя роль HTTP-контроллер здесь.

Взяв во внимание Объект передачи данных (ДТО)это ГрафQL схема аргументов запроса, определенная с помощью декоратора Javascript @Args предоставлено NestJS.

Репозиторий

Преобразователь PokémonResolver вызывает репозиторий покемонов, внедренный в его контекст через интерфейс репозитория из Презентация слой.

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

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

Картограф

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

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

Ведущий

Наконец, данные передаются движку GraphQL (т. Ведущий на схеме) в Pokédex тренера покемонов.

Вывод

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

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

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

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

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