Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
NestJS-tRPCと戦術的DDDのいいとこどりをしてバックエンドTypescriptの設計...
Search
与謝秀作
March 17, 2025
Technology
0
390
NestJS-tRPCと戦術的DDDのいいとこどりをしてバックエンドTypescriptの設計をした話
与謝秀作
March 17, 2025
Tweet
Share
Other Decks in Technology
See All in Technology
伴走から自律へ: 形式知へと導くSREイネーブリングによる プロダクトチームの信頼性オーナーシップ向上 / SRE NEXT 2025
visional_engineering_and_design
3
230
マーケットプレイス版Oracle WebCenter Content For OCI
oracle4engineer
PRO
3
990
ロールが細分化された組織でSREは何をするか?
tgidgd
1
200
[SRE NEXT] ARR150億円_エンジニア140名_27チーム_17プロダクトから始めるSLO.pdf
satos
5
2.1k
クラウド開発の舞台裏とSRE文化の醸成 / SRE NEXT 2025 Lunch Session
kazeburo
1
450
United Airlines Customer Service– Call 1-833-341-3142 Now!
airhelp
0
180
サイバーエージェントグループのSRE10年の歩みとAI時代の生存戦略
shotatsuge
4
830
いつの間にか入れ替わってる!?新しいAWS Security Hubとは?
cmusudakeisuke
0
160
How to Quickly Call American Airlines®️ U.S. Customer Care : Full Guide
flyaahelpguide
0
240
[ JAWS-UG千葉支部 x 彩の国埼玉支部 ]ムダ遣い卒業!FinOpsで始めるAWSコスト最適化の第一歩
sh_fk2
2
150
DatabricksにOLTPデータベース『Lakebase』がやってきた!
inoutk
0
150
Amplify Gen2から知るAWS CDK Toolkit Libraryの使い方/How to use the AWS CDK Toolkit Library as known from Amplify Gen2
fossamagna
1
240
Featured
See All Featured
The Straight Up "How To Draw Better" Workshop
denniskardys
235
140k
Practical Orchestrator
shlominoach
189
11k
Art, The Web, and Tiny UX
lynnandtonic
299
21k
Building a Modern Day E-commerce SEO Strategy
aleyda
42
7.4k
Building an army of robots
kneath
306
45k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
281
13k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
740
What's in a price? How to price your products and services
michaelherold
246
12k
Site-Speed That Sticks
csswizardry
10
700
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
A designer walks into a library…
pauljervisheath
207
24k
The Art of Programming - Codeland 2020
erikaheidi
54
13k
Transcript
NestJS-tRPCと戦術的DDDのい いとこどりをしてBackend Typescriptの設計をした話 by Ficilcom CEO YOSA
自己紹介 東京大学工学部システム創成学科卒業 日鉄ソリューションズ(SIer) :システムエンジニア bestat(松尾研系スタートアップ) :機械学習エンジニア ZOZO(自社サービス) :推薦エンジニア 独立、現在2個目のプロダクトを開発中(今日はここの話) ←Web
DB Press vol.129 「レコメンドエンジン総実装」 ↓ https://zenn.dev/yosashusaku
祝!2年ぶりの開催 この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に使う フロントと型を共有) このサンプルでは1ファイルに 書いているが、実際に
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開催
ご清聴ありがとうございました