はじめに
この記事は「リファクタリングを通して学ぶドメイン駆動設計」シリーズのPart7（最終回）です。
前回はコントローラー(Controller) の実装について説明しました。今回は依存性注入(Dependency Injection) について解説し、これまで作成してきた各層を組み立てて、実際に動作するアプリケーションを完成させます。
開発環境
開発環境は以下の通りです。
- Windows11
- Docker Engine 27.0.3
- Docker Compose 2
- PostgreSQL 18.1
- Node.js 24.11.0
- npm 11.6.2
- TypeScript 5.9.3
- Express 5.1.0
- Prisma 6.18.0
- Zod 4.1.12
依存性注入の設定
依存性注入(Dependency Injection: DI) とは、クラスが必要とする他のクラスを外部から渡す手法です。
エントリーポイントで各層のインスタンスを生成し、依存関係を解決します。
// main.ts
import express from 'express';
import { PrismaClient } from '@prisma/client';
const app = express();
const prisma = new PrismaClient();
const PORT = process.env.PORT || 3000;
app.use(express.json());
// 依存性注入の設定
const userRepository = new PrismaUserRepository(prisma);
const createUserUseCase = new CreateUserUseCase(userRepository);
const getUserUseCase = new GetUserUseCase(userRepository);
const getAllUsersUseCase = new GetAllUsersUseCase(userRepository);
const updateUserUseCase = new UpdateUserUseCase(userRepository);
const deleteUserUseCase = new DeleteUserUseCase(userRepository);
const userController = new UserController(
createUserUseCase,
getUserUseCase,
getAllUsersUseCase,
updateUserUseCase,
deleteUserUseCase
);
// ルーティング
app.get('/', (req, res) => {
res.json({ message: 'Server is running' });
});
app.post('/users', (req, res) => userController.create(req, res));
app.get('/users', (req, res) => userController.getAll(req, res));
app.get('/users/:id', (req, res) => userController.getById(req, res));
app.put('/users/:id', (req, res) => userController.update(req, res));
app.delete('/users/:id', (req, res) => userController.delete(req, res));
app.listen(PORT, () => {
console.log(`Server is running on port ${PORT}`);
});
process.on('SIGINT', async () => {
await prisma.$disconnect();
process.exit(0);
});
依存関係の流れ
依存性注入により、以下のような依存関係が構築されます。
main.ts
├─ PrismaClient (Prisma)
│ └─ PrismaUserRepository (インフラ層)
│ ├─ CreateUserUseCase (アプリケーション層)
│ ├─ GetUserUseCase (アプリケーション層)
│ ├─ GetAllUsersUseCase (アプリケーション層)
│ ├─ UpdateUserUseCase (アプリケーション層)
│ └─ DeleteUserUseCase (アプリケーション層)
│ └─ UserController (プレゼンテーション層)
│ └─ setupUserRoutes (ルーティング)
└─ Express App
依存性注入のポイント
ポイント1: 依存関係の一方向性
依存関係は常に外側から内側へ向かいます。
プレゼンテーション層
↓ 依存
アプリケーション層
↓ 依存
ドメイン層
↓ 依存（インターフェース経由）
インフラ層
重要な原則:
- ドメイン層は他の層に依存しない
- アプリケーション層はドメイン層にのみ依存
- インフラ層はドメイン層のインターフェースを実装
- プレゼンテーション層はアプリケーション層に依存
ポイント2: インスタンス生成の順序
依存性注入では、インスタンスを依存される側から生成します。
// 1. 最も依存されるもの（インフラ層）
const prisma = new PrismaClient();
const userRepository = new PrismaUserRepository(prisma);
// 2. 中間層（アプリケーション層）
const createUserUseCase = new CreateUserUseCase(userRepository);
const getUserUseCase = new GetUserUseCase(userRepository);
// ...
// 3. 最も依存するもの（プレゼンテーション層）
const userController = new UserController(
createUserUseCase,
getUserUseCase,
getAllUsersUseCase,
updateUserUseCase,
deleteUserUseCase
);
ポイント3: テスト時の差し替え
依存性注入により、テスト時に実装を差し替えられます。
// 本番環境
const userRepository = new PrismaUserRepository(prisma);
const useCase = new CreateUserUseCase(userRepository);
// テスト環境
const mockRepository: IUserRepository = {
save: jest.fn(),
findById: jest.fn(),
findAll: jest.fn(),
update: jest.fn(),
delete: jest.fn(),
existsByEmail: jest.fn(),
};
const useCase = new CreateUserUseCase(mockRepository);
ポイント4: 変更への柔軟性
データベースを変更する場合、リポジトリの実装を差し替えるだけです。
// Prismaを使用
const userRepository = new PrismaUserRepository(prisma);
// TypeORMに変更
const userRepository = new TypeORMUserRepository(dataSource);
// ユースケース以降は変更不要
const createUserUseCase = new CreateUserUseCase(userRepository);
const userController = new UserController(createUserUseCase, ...);
ディレクトリ構成
完成したアプリケーションのディレクトリ構成は以下のようになります。
src/
├── domain/ # ドメイン層
│ ├── entities/
│ │ └── User.ts
│ ├── value-objects/
│ │ ├── Email.ts
│ │ ├── UserName.ts
│ │ └── UserId.ts
│ └── repositories/
│ └── IUserRepository.ts
├── application/ # アプリケーション層
│ └── usecases/
│ ├── CreateUserUseCase.ts
│ ├── GetUserUseCase.ts
│ ├── GetAllUsersUseCase.ts
│ ├── UpdateUserUseCase.ts
│ └── DeleteUserUseCase.ts
├── infrastructure/ # インフラ層
│ └── prisma/
│ └── PrismaUserRepository.ts
├── presentation/ # プレゼンテーション層
│ ├── controllers/
│ │ └── UserController.ts
│ └── routes/
│ └── userRoutes.ts
├── middlewares/
│ └── validate.middleware.ts
├── schemas/
│ └── user.schema.ts
└── index.ts # エントリーポイント
まとめ
全7回にわたり、DDDを使ったリファクタリングについて解説してきました。
各回の内容
- Part1: 値オブジェクトの作成
- Part2: エンティティの作成
- Part3: リポジトリインターフェースの定義
- Part4: ユースケースの作成
- Part5: リポジトリの実装
- Part6: コントローラーの実装
- Part7: 依存性注入の設定（今回）
DDDの重要な概念
| 概念 | 説明 | 配置される層 |
|---|---|---|
| 値オブジェクト | 値そのものを表すオブジェクト | ドメイン層 |
| エンティティ | 一意の識別子を持つオブジェクト | ドメイン層 |
| リポジトリ | データ永続化の抽象化 | ドメイン層（インターフェース） インフラ層（実装） |
| ユースケース | アプリケーションの具体的な操作 | アプリケーション層 |
| コントローラー | HTTPリクエスト/レスポンスの処理 | プレゼンテーション層 |
| 依存性注入 | インスタンスを外部から渡す | エントリーポイント |
DDDのメリットとデメリット
DDDを適用することで以下のメリットがあります。
- ビジネスルールが明確になる
- 値オブジェクトとエンティティでドメイン知識を表現できる
- 「ユーザーとは何か」「メールアドレスとは何か」が明確になる
- 保守性が向上する
- 各層が独立しているため、変更の影響範囲が限定的
- データベースを変更してもドメイン層は影響を受けない
- テストしやすくなる
- リポジトリをモックに差し替えやすい設計
- ユースケース単位でテストできる
- チーム開発がしやすい
- 責務が明確なので、並行作業がしやすくなる
一方、以下のようなデメリットがあります。
- コード量が増える
- 層を分離することで、ファイル数とコード量が増える
- 学習コストがかかる
- DDDの概念（エンティティ、値オブジェクト、リポジトリなど）を理解する必要がある
そのため、以下の場合は過剰設計になる可能性があります。
- シンプルなCRUDアプリケーション
- 短期間で使い捨てのプロトタイプ
- 個人の小規模プロジェクト
そのため、今回のようなシンプルなCRUDアプリケーションでは過剰設計ですが、DDDの各概念を理解する良い練習になったと思います。