DDDとクリーンアーキテクチャをはじめよう
背景
ども！池田(ikedadada)です！
最近はもっぱらコードばっかり書いていたのですが、筆不精解消のために何かしら書いてみようと思い立ちました。
私はDDD（ドメイン駆動設計）とクリーンアーキテクチャを組み合わせた設計手法を好んで使っており、各言語の習得の際には一度、TodoアプリをDDDとクリーンアーキテクチャで実装しています。
しかし、各言語での実装例をまとめた記事はあまり見かけないので、今後いくつかの記事に分けて書いていきます。
今回はその第一弾として、DDDとクリーンアーキテクチャの概要と基本的な考え方を紹介します。
DDD（ドメイン駆動設計）とは
ドメイン駆動設計（ドメインくどうせっけい、英語: domain-driven
design、DDD）は主要なソフトウェア設計手法の一つであり、ドメインエキスパートの言葉に基づき、ドメインにおけるプロセスやルールをよく表現したドメインモデルを構築し、それに基づいてソフトウェア開発を行うことに主眼を置くものである。--
Wikipedia 「ドメイン駆動設計」より
設計手法自体の説明はWikipediaに譲るとして、私の理解では「ドメイン（業務領域）に関する知識を中心に各情報と機能を整理し、ソフトウェア設計に反映させる手法」と考えています。
個人的には以下の本がおすすめです。
クリーンアーキテクチャとは
こちらはWikipediaに記事がないようなので、概要を説明します。
クリーンアーキテクチャは、ソフトウェアの構造を整理し、保守性や拡張性を高めるための設計原則とパターンの集合です。ロバート・C・マーチン（通称 Uncle
Bob）が提唱しました。クリーンアーキテクチャの主な特徴は以下の通りです。
- 層構造: ソフトウェアを複数の層に分割し、各層が特定の責任を持つように設計する。
- 依存関係のルール: 内側の層は外側の層に依存してはならず、依存の方向を統一することで、外側にある技術的な詳細による影響から内側のビジネスロジックを保護する。
- インターフェースの使用: 各層は明確なインターフェースを持ち、他の層との依存関係を最小限に抑える。これにより、各層の実装を変更しても、他の層に影響を与えにくくなる。
- テスト容易性: 各層が独立しているため、ユニットテストや統合テストが容易になる。
原著以外でおすすめな本がないので、頑張ってこちらを読んでください。
深呼吸
DDDやクリーンアーキテクチャを実現することにより、ビジネスロジックをコードに落とし込むことができ、保守性や拡張性の高いソフトウェアを構築できます。ただし、これらの設計手法は学習、設計、実装に時間と労力がかかるため、プロジェクトの規模や要件に応じて適用を検討することが重要だと考えています。
先に紹介した「ドメイン駆動設計をはじめよう」内にも書かれていますが、競争優位性を持つドメインに対してはDDDを適用し、そうでない場合はシンプルな設計を選択することが推奨されています。
ただ技術的な影響からビジネスロジックを守るという設計は開発者にとってもビジネスロジックに対する理解を深めることができるため、特に自己学習の際には非常に有効だと感じています。
サンプルのTodo API実装要件
今回は各言語での実装例を示し、比較検討可能とすることを目的としているため、要件はシンプルにしています。
各言語で実装する際の要件は以下の通りです。
対象リソース
TODOモデル
フィールド
- id(UUID)
- title(文字列)
- description(任意文字列)
- completed(bool)
ユースケース
- 全件取得
- 1件取得
- 新規作成（作成時にはTODOは未完了）
- 上書き更新（完了フラグは変更不可）
- 削除
- 完了フラグを立てる
- 完了フラグを外す
エンドポイント
- GET
/todos/: 全件取得- 200: Todo[]
- GET
/todos/{id}: 1件取得- 200: Todo
- 404: Not Found
- POST
/todos/: 新規作成- Body: { title, description? }
- 201: 作成Todo（idはサーバ生成、completed=false）
- PUT
/todos/{id}: 上書き更新- Body: { title, description? }
- 200: 更新後Todo
- 404: Not Found
- DELETE
/todos/{id}: 削除- 204: No Content
- 404: Not Found
- PUT
/todos/{id}/complete: 完了フラグを立てる- 200: 更新後Todo
- 409: 既に完了
- 404: Not Found
- PUT
/todos/{id}/uncomplete: 完了フラグを外す- 200: 更新後Todo
- 409: 未完了
- 404: Not Found
インフラ方針
- データベースはMySQLを使用
- 各アプリケーションはコンテナ化し、Docker Composeで起動可能とする
- 各アプリケーションはローカル環境で起動可能とする
まとめ
今回はDDDとクリーンアーキテクチャの概要と基本的な考え方、そしてサンプルのTodo
API実装要件を紹介しました。
次回以降の記事では、具体的な言語での実装例を示していきますので、ぜひお楽しみにしてください！
実装予定リポジトリ:
Discussion