NestJS-tRPCと戦術的DDDのいいとこどりをしてバックエンドTypescriptの設計をした話

NestJS-tRPCと戦術的DDDのいいとこどりをしてBackend　 Typescriptの設計をした話 by Ficilcom CEO YOSA

自己紹介東京大学工学部システム創成学科卒業日鉄ソリューションズ（SIer）：システムエンジニア bestat（松尾研系スタートアップ）：機械学習エンジニア ZOZO（自社サービス）：推薦エンジニア独立、現在２個目のプロダクトを開発中（今日はここの話） ←Web
DB Press vol.129 「レコメンドエンジン総実装」 ↓　https://zenn.dev/yosashusaku

祝！２年ぶりの開催この2年でNestJSの（個人的に一番の）大きな変化といえば、、、

NestJS tRPCのローンチ（2024/06） https://www.nestjs-trpc.io/ tRPCの作者(KevinEdry) が開発 →Monorepo内のBackend　 Typescriptとして有力　な候補に

tRPCとは client/serverでTS の型を共有 Monorepo前提 →とにかく開発体験がいい！！

前提条件：Turborepoを使った開発 https://turbo.build/repo/ Vercel製のTS/JS専用Monorepo管理ツール - リモートキャッシュ - タスクの依存解決 - テストやビルドの並列実行 Monorepo開発における強力な機能が多い
（Full TS前提だと特におすすめ） pnpm workspaceの拡張で右図のようなディレクトリ構成になっている

NestJS tRPCの設定 apps/api/src/app.module.ts packages/trpc/@generatedに自動生成 →フロントから呼び出せる

NestJS tRPCの実装例 NestJS tRPC専用のデコレータ DTOの代わりに Zodでスキーマ定義（InputとOutputに使うフロントと型を共有）このサンプルでは１ファイルに書いているが、実際に
Module内は Router / Schema / Service で構成される。

NestJS tRPCのその他のメリット Validationの違い：Zodになったことでフロントと共有できるテクニックが使える class-validator 　　　　　　　　　　→ Zod

おまけ：tRPC-Panel Swagger UIのtRPC版 APIエンドポイントの Documentを自動生成

NestJSでもMonorepo構成を活かしたtRPCによる開発体験を得ることができるゾさて、 NestJSを使った開発に入る前に

NestJSは巷で言われているように too much なフレームワークなのだろうか？

APIサーバの役割をDDDの層に分解すると

NestJSの機能を当てはめると Controller / Router DTO / Schema Service

Serviceファイルに詰め込み過ぎじゃない？ Serviceファイルにドメイン層・ユースケース層・インフラ層の責務を持たせる（Fat Service問題）のは無謀ではないか →改修困難なコード、人によってバラツくコーディングルール NestJSがtoo muchというのは嘘だと思う ※むしろnot enoughに感じた

NestJSで足りない部分は戦術的DDDで補う DDDの部分はpackages/coreに切り出そう！ →ドメイン層とユースケース層はapps/apiを離れて packages/coreに移動する。 apps/api：NestJS（DI、デコレータなど） packages/core：DDD（domain、usecase、error）それぞれの文脈で開発を言葉を分けられる

戦略的DDDの構成要素ドメイン層 - ビジネスロジックをエンティティや値オブジェクトに閉じ込め、純粋なビジネスルールとして実装します。 - entity / value-object /
aggregate / domain-service / repository(I/F) ユースケース層 - ユースケースに沿った処理を実装し、ドメイン層のオブジェクトを組み合わせてビジネスプロセスを実現します。インフラ層 - 永続化や外部サービスとの連携など、技術的な実装を担います。ここでは、Prisma などのORMが利用され、実際のデータアクセスを管理します。

ドメイン駆動設計における依存の方向 api：ライブラリや外部アクセス　　 (ORM等)に依存する core：純粋なビジネスロジックを表現　ライブラリ等に依存しない　PureなTypescriptで実装する apiはcoreに依存する。それぞれ分離することで、TestableでSOLIDな構成になる。

Turborepoを使った依存関係の管理 packages/core/package.json 余計なライブラリを入れない apps/api/package.json dependenciesでcoreへの依存を定義 core → api の順にtestやbuildを実行 DDDの依存関係をpackageで管理できた

依存方向のディレクトリ構成対応 ① ② ③ ① ② ③ ※依存元→依存先

依存性逆転の法則（実例）インフラ層をリポジトリに注入 (=依存性逆転) Repository(I/F) を使ってusecase を定義

依存性逆転の法則（実例解説）前ページの実装例では AuthJSを活用して認証を行っているため、api配下ではAuthというModuleに属している。ところが、core配下ではAuthJSというライブラリには依存したくないため、 ”createUser” といったビジネスドメインでの定義をしている。 ↓ core配下をPureなTypescriptを使って（＝外部ライブラリやサードパーティに依存せず）ビジネスドメインを表現している。

いつでもNestJSを剥がせる（↑NestJSのmeetupで言うことじゃない！）

まとめ Tureborepoの性質をフル活かすことで、 ①NestJSでもtRPCという極上の開発体験を得られる ②NestJSとTS DDDのいいとこどりをした開発ができる

告知①：エンジニア募集中 Typescript DDDだけじゃなくておもしろい技術スタック使ってるよ！募集職種：Typescript芸人　プロダクトエンジニア建設業というドメイン（→DDDを使いたかった）

告知②：TSKaigi 2025開催

ご清聴ありがとうございました

NestJS-tRPCと戦術的DDDのいいとこどりをしてバックエンドTypescriptの設計...