Clean Architecture by TypeScript & NestJS

クリーンアーキテクチャを学んで 実装してみた経験をお話します

Clean Architecture とは ビジネスロジックを中心におき、インタフェースや技術を外側に配置する設計アプローチ 依存の向きは常に内側を向き、ユースケースと周辺の関心事を分離する 持つ特性 ● フレームワーク非依存 ● テスト可能 ● UI 非依存 ● データベース非依存 ● 外部エージェント非依存 Clean Architecture 達人に学ぶソフトウェアの構造と設計

4 つのレイヤー Enterprise Business Rules Entities と呼ばれる、ビジネスルールをカプセル化したものが存在するレイヤ− Application Business Rules システムのユースケースがカプセル化・実装されているレイヤー Interface Adapters 円の内側に便利な形から、Web や DB などに便利な形に変換するレイヤー Frameworks & Drivers フレームワークやツールで構成されるレイヤー (必ずしも 4 つである必要はない ただし依存関係の向きだけは守る必要がある)

Web ベースのシステムに落とし込むと 依存の向きを見てみると、 全てが依存性のルールに従って、 内側に向いている Clean Architecture 達人に学ぶソフトウェアの構造と設計

実装 お題 : Todo アプリ 使用技術 : TypeScript, NestJS, Prisma リポジトリ : https://github.com/ryounasso/todo-app-by-clean-architecture

Entity constructor / getter は省略

Usecase ( Service )

Interface ( Controller )

Interface ( Repository )

じゃあこの Todo アプリでできることは？

この Todo アプリでできること

実装振り返り

実装振り返り Presenter を実装していない

実装振り返り getTodoList の返り値 当初は、Todo Entity の内容全てを返す設計 ↓ ユースケースとして、 Todo の一覧をユーザーが見るときに、 全ての情報が欲しいケースがありそうか？ → なさそう

実装振り返り getTodoList の返り値 ユーザーが欲しいフィールドを返す設計に変更

まとめ ● 各レイヤーに意図があり、それらの間に境界を設けて、 分けて管理することで可動性の向上を実感 ● ユースケースをしっかり考えることが重要 ● DB や Framework の置き換えのコストを減らせる ● テストがしやすい

参考資料 ● Clean Architecture 達人に学ぶソフトウェアの構造と設計 ● The Clean Architecture https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architectur e.html