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
クリーンアーキテクチャの NodeJSによる実装例
Search
Templiver
December 06, 2022
Programming
0
1.4k
クリーンアーキテクチャの NodeJSによる実装例
Templiver
December 06, 2022
Tweet
Share
More Decks by Templiver
See All by Templiver
大量データをRedisに入れる際の 容量問題にどう対処したか
terashin
0
1.4k
Other Decks in Programming
See All in Programming
DockerからECSへ 〜 AWSの海に出る前に知っておきたいこと 〜
ota1022
5
1.2k
Constant integer division faster than compiler-generated code
herumi
2
660
自作OSでDOOMを動かしてみた
zakki0925224
1
1.3k
Infer入門
riru
4
1.5k
バイブコーディングの正体——AIエージェントはソフトウェア開発を変えるか?
stakaya
5
940
DynamoDBは怖くない!〜テーブル設計の勘所とテスト戦略〜
hyamazaki
1
200
書き捨てではなく継続開発可能なコードをAIコーディングエージェントで書くために意識していること
shuyakinjo
1
280
STUNMESH-go: Wireguard NAT穿隧工具的源起與介紹
tjjh89017
0
380
可変性を制する設計: 構造と振る舞いから考える概念モデリングとその実装
a_suenami
10
1.8k
JetBrainsのAI機能の紹介 #jjug
yusuke
0
200
Langfuseと歩む生成AI活用推進
licux
3
250
なぜ今、Terraformの本を書いたのか? - 著者陣に聞く!『Terraformではじめる実践IaC』登壇資料
fufuhu
4
620
Featured
See All Featured
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
283
13k
A designer walks into a library…
pauljervisheath
207
24k
The World Runs on Bad Software
bkeepers
PRO
70
11k
It's Worth the Effort
3n
186
28k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
[RailsConf 2023] Rails as a piece of cake
palkan
56
5.8k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
50
5.5k
Agile that works and the tools we love
rasmusluckow
329
21k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
Optimising Largest Contentful Paint
csswizardry
37
3.4k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.5k
Transcript
クリーンアーキテクチャの NodeJSによる実装例
1. クリーンアーキテクチャ
クリーンアーキテクチャとは? コントローラー - コントローラー - ミドルウェア - DTO リポジトリ -
リポジトリ - UnitOfWork - DTO ユースケース(サービス) - ユースケース ドメイン - ドメインサービス - ドメインモデル - バリデーター - 便利関数 - 外部ライブラリのラッパー - 設定/環境変数オブジェクト DIP 下に 依存
コントローラーとは? 1. リクエストからサービスが必要な情報を抽出 2. サービスが返す情報をレスポンスの形にする
コントローラーとは? 取得系APIの例 (ts) DTOをドメインモデルに変換 ドメインモデルをDTOに変換 レスポンスでのみ必要な値などは このタイミングで生成する
コントローラーとは? 更新系APIの例 (ts)
DTOとは? 外部とのやり取りに使うパラメータなどの マッピング先オブジェクト
DTOとは? DTOの例 (ts)
リポジトリとは? 外部のサービス(DBやAPIなど)と データのやり取りをする
リポジトリとは? リポジトリの例 (ts)
UnitOfWork(UoW)とは? トランザクション処理をハンドリングする
UnitOfWork(UoW)とは? UoWの例 (ts) 生成 UoWのファクトリ例 (ts)
UnitOfWork(UoW)とは? UoWの使用例 (ts) UoWを生成 トランザクションの開始 トランザクションのコミット ロールバック
ユースケース(サービス)とは? ドメインロジックやリポジトリなどがする処理の フローを制御する
ユースケース(サービス)とは? リポジトリのインタフェースに依 存(DIP) ユースケースの例 (ts) リポジトリ ユースケース リポジトリの インタフェース
ドメインサービスとは? ドメインモデルとして定義すると違和感のある ドメインロジックを処理する
※ ドメインロジックとは? サービス固有のロジック
ドメインサービスとは? ドメインサービスの例 (ts)
ドメインモデルとは? ドメインロジックを処理する
ドメインモデルとは? ドメインモデルの例 (ts)
プリミティブ型のみに依存する関数 便利関数とは?
便利関数とは? 便利関数の例 (ts)
外部ライブラリのラッパーとは? 外部ライブラリのラッパー例 (ts) 処理の差し込みが可能
※ 値オブジェクト 基本、値オブジェクトは使わない 必要になったら データの入れ替えがより大変になるので
※ 値オブジェクト 値オブジェクトの例 (ts) :期間を表す
2. アーキテクチャの評価
デメリットは? • データの入れ替えが大変 • DIPが起こるところの書き方が冗長
デメリット: データの入れ替えが大変 例: APIリクエストパラメータ -> ドメインモデル 例: SQLレスポンス -> ドメインモデル
メリットは? • ドメインロジックを再利用しやすい • ドメインロジックの記述箇所を特定するのが容易 • 変更箇所を最小限にできるため、改善しやすい • 処理が適切な粒度で分けられて、コードの見通しが良くなる •
実装をモックで置き換えられるので、テストが書きやすい
3. その他、開発で気をつけていること
開発の方針 • 関数にわかりやすい名前をつける わかりやすい関数名さえあればコメントは基本いらない • 適切な粒度で関数に切り出す 目安は、わかりやすい関数名がつけられる粒度 関数名だけで処理を書いて、後でその実装を書く • テストが書きやすいかを意識する
• 何がドメインロジックかよく考える • ドメインロジックはできる限りドメインモデルに定義する そうしないと、再利用性の低いコードになる(ドメインモデル貧血症になる...)
適切な粒度で関数に切り出すには? こういう関数があったら良いな、 という気持ちで関数名で 処理の流れを書く 関数名に対応する実装を書く
テストが書きやすいかを意識するとはどういうことか • どういう粒度でテストしたいか 適切な粒度で処理を切り出し、名前をつけられる • 変数をここに定義して良いのか グローバル変数などを使うと、見えない情報によってテストしづらくなる • DIするのは何故か モックに置き換えて単体テストしやすくなる
• 引数がオブジェクトで良いのか テストの時オブジェクト生成が面倒くさい、どの情報が本当に必要なのかわからなくなる • 分岐が沢山あった時困らないか 一つの関数に対するテストケースが増える
最後に ベースとなるアーキテクチャを持ちつつも、 自分達のサービスに合わせて変えていく ベースとなるアーキテクチャが何もないと 何が良くて何が悪いかが分からず、改善しにくい