はじめに
この記事は、以下の記事の続きです。
今回はユースケースの作成について説明します。
開発環境
開発環境は以下の通りです。
- 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
インフラ層での実装
Part3でリポジトリのインターフェースを定義しました。今回は、そのインターフェースをPrismaを使って具体的に実装します。
domain/repositories/IUserRepository.ts
export interface IUserRepository {
save(user: User): Promise<User>;
findById(id: UserId): Promise<User | null>;
findAll(): Promise<User[]>;
update(user: User): Promise<User>;
delete(id: UserId): Promise<void>;
existsByEmail(email: Email): Promise<boolean>;
}
インフラ層の役割
インフラ層は、技術的な実装の詳細を担当する層です。データベース、外部API、ファイルシステムなど、具体的な技術に依存する処理をここに配置します。
ドメイン層で定義したインターフェースを、この層で具体的に実装することで、ドメイン層を技術的な詳細から保護します。
リポジトリの実装
Prismaを使ってリポジトリを実装します。
infrastructure/prisma/PrismaUserRepository.ts
import { PrismaClient } from '@prisma/client';
export class PrismaUserRepository implements IUserRepository {
constructor(private readonly prisma: PrismaClient) {}
async save(user: User): Promise<User> {
const data = await this.prisma.user.create({
data: {
email: user.getEmail().getValue(),
name: user.getName().getValue(),
},
});
return User.reconstruct(
new UserId(data.id),
new Email(data.email),
new UserName(data.name)
);
}
async findById(id: UserId): Promise<User | null> {
const data = await this.prisma.user.findUnique({
where: { id: id.getValue() },
});
if (!data) {
return null;
}
return User.reconstruct(
new UserId(data.id),
new Email(data.email),
new UserName(data.name)
);
}
async findAll(): Promise<User[]> {
const users = await this.prisma.user.findMany();
return users.map(data =>
User.reconstruct(
new UserId(data.id),
new Email(data.email),
new UserName(data.name)
)
);
}
async update(user: User): Promise<User> {
const data = await this.prisma.user.update({
where: { id: user.getId().getValue() },
data: {
email: user.getEmail().getValue(),
name: user.getName().getValue(),
},
});
return User.reconstruct(
new UserId(data.id),
new Email(data.email),
new UserName(data.name)
);
}
async delete(id: UserId): Promise<void> {
await this.prisma.user.delete({
where: { id: id.getValue() },
});
}
async existsByEmail(email: Email): Promise<boolean> {
const count = await this.prisma.user.count({
where: { email: email.getValue() },
});
return count > 0;
}
}
ポイント1. ドメインオブジェクトとDBモデルの変換
リポジトリの重要な役割の1つは、ドメインオブジェクトとデータベースモデルの変換です。
保存時: ドメインオブジェクト → DBモデル
async save(user: User): Promise<User> {
// ドメインオブジェクトから値を取り出す
const data = await this.prisma.user.create({
data: {
email: user.getEmail().getValue(), // Email値オブジェクト → string
name: user.getName().getValue(), // UserName値オブジェクト → string
},
});
// ...
}
ドメインオブジェクトは値オブジェクトを持っていますが、データベースにはプリミティブ型で保存します。
取得時: DBモデル → ドメインオブジェクト
async findById(id: UserId): Promise<User | null> {
const data = await this.prisma.user.findUnique({
where: { id: id.getValue() },
});
if (!data) {
return null;
}
// DBから取得したプリミティブ型をドメインオブジェクトに変換
return User.reconstruct(
new UserId(data.id), // number → UserId値オブジェクト
new Email(data.email), // string → Email値オブジェクト
new UserName(data.name) // string → UserName値オブジェクト
);
}
データベースから取得したプリミティブ型のデータを、値オブジェクトに変換してエンティティを再構築します。
なぜ変換が必要なのか:
- ドメイン層では型安全な値オブジェクトを使いたい
- データベースはプリミティブ型で保存する
- この変換はインフラ層の責務
ポイント2. Prismaへの依存はこの層だけ
元のコードでは、コントローラーから直接Prismaを呼び出していました。
// Before: Prismaへの依存がコントローラーに漏れている
app.post("/users", async (req, res) => {
const user = await prisma.user.create({
data: { email, name },
});
res.status(201).json(user);
});
リポジトリパターンを使うことで、Prismaへの依存をインフラ層に閉じ込められます。
// After: Prismaへの依存はリポジトリだけ
export class PrismaUserRepository implements IUserRepository {
constructor(private readonly prisma: PrismaClient) {}
// Prismaを使った実装
}
メリット:
- 将来的にPrismaから別のORM（TypeORM、Drizzleなど）に変更しやすい
- リポジトリの実装を差し替えるだけで、他の層に影響を与えない
- ドメイン層とアプリケーション層がデータベースの詳細を知らなくて済む
ポイント3. エラーハンドリング
リポジトリでは、データベース固有のエラーをドメイン固有のエラーに変換することもできます。
async save(user: User): Promise<User> {
try {
const data = await this.prisma.user.create({
data: {
email: user.getEmail().getValue(),
name: user.getName().getValue(),
},
});
return User.reconstruct(
new UserId(data.id),
new Email(data.email),
new UserName(data.name)
);
} catch (error) {
// Prisma固有のエラーをドメインのエラーに変換
if (error instanceof Prisma.PrismaClientKnownRequestError) {
if (error.code === 'P2002') {
throw new Error('Email already exists');
}
}
throw error;
}
}
ただし、今回のサンプルでは簡潔さのためエラーハンドリングは省略しています。
ポイント4. 一貫性のあるインターフェース
リポジトリのメソッドは、常にドメインオブジェクトを受け取り、ドメインオブジェクトを返します。
// 受け取る: ドメインオブジェクト
async save(user: User): Promise<User>
async findById(id: UserId): Promise<User | null>
async update(user: User): Promise<User>
async delete(id: UserId): Promise<void>
// プリミティブ型は受け取らない（NG）
async findById(id: number): Promise<User | null> // NG
メリット:
- 使う側（ユースケース）が扱いやすい
- 型安全性が保たれる
- ドメインの概念が一貫している
まとめ
今回は、DDDにおけるリポジトリ(Repository) の実装について説明しました。
- ポイント
- リポジトリはドメインオブジェクトとDBモデルを変換する
- データベース固有の技術への依存をインフラ層に閉じ込める
- インターフェースを実装することで、実装を差し替え可能にする
- ドメインオブジェクトを受け取り、ドメインオブジェクトを返す
- メリット
- データベースの実装詳細がドメイン層に漏れない
- ORMの変更が容易
- テスト用のモックを作りやすい
- ドメイン層とアプリケーション層がシンプルになる
次回は、コントローラーの実装について説明します。