Go to Qiita Advent Calendar Top
LoginSignup
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@iwata-goq(岩田 康平)in株式会社GoQSystem

PHPにおけるDTO（Data Transfer Object）の実践的活用法

Last updated at Posted at 2025-10-23

API開発やフロントエンド・バックエンド間のデータ通信を行う際、「データをどう扱うか」は重要な設計判断です。本記事では、PHPにおけるDTOパターンの活用方法と、その実践的なメリットについて解説します。

DTOとは何か

DTO（Data Transfer Object） は、異なるレイヤー間やシステム間でデータを転送するために使用される専用のオブジェクトです。

「異なるレイヤー間」とは？

レイヤードアーキテクチャを採用したWebアプリケーション（例：MVCパターンを使用したフレームワーク）では、以下のような層（レイヤー）で構成されることがあります：

クライアント（ブラウザ/モバイルアプリ）
    ↕ HTTP通信
コントローラー層（APIエンドポイント）
    ↕
サービス層（ビジネスロジック）
    ↕
リポジトリ層（データアクセス）
    ↕
データベース

これらの各層の間でデータをやり取りする際、それぞれの層が持つデータの形式や必要な情報は異なります。例えば：

  • データベース層: user_id、password_hash、deleted_atなどの内部的なカラム名と情報
  • サービス層: Userエンティティとして、ビジネスロジックを含むオブジェクト
  • API層: id、username、emailなど、クライアントに公開する情報のみ

DTOは、これらの層の間でデータを橋渡しする役割を担います。

注意: アーキテクチャパターンはMVCだけでなく、クリーンアーキテクチャやヘキサゴナルアーキテクチャなど様々な選択肢があります。DTOはこれらのパターンにおいても、境界を越えたデータ転送に活用できます。

DTOの主な特徴

  • データ転送専用: ビジネスロジックを持たず、データの保持と転送のみに特化
  • 明確な境界: レイヤー間の責任を明確に分離
  • 変換の中継点: 外部データを内部モデルに、または内部モデルを外部形式に変換

Martin Fowlerによる定義では、DTOは「メソッド呼び出しの回数を減らすために複数のパラメータをまとめて転送するオブジェクト」とされています。

PHPでのDTO表現

PHPでは、主に以下の方法でDTOを表現できます。

1. Class を使用した定義（基本）

<?php

// レスポンス用DTO
class UserResponseDto
{
    public string $id;
    public string $username;
    public string $email;
    public string $createdAt;

    public function __construct(
        string $id,
        string $username,
        string $email,
        string $createdAt
    ) {
        $this->id = $id;
        $this->username = $username;
        $this->email = $email;
        $this->createdAt = $createdAt;
    }
}

// リクエスト用DTO
class CreateUserRequestDto
{
    public string $username;
    public string $email;
    public string $password;

    public function __construct(
        string $username,
        string $email,
        string $password
    ) {
        $this->username = $username;
        $this->email = $email;
        $this->password = $password;
    }
}

2. Readonly プロパティを使用した定義（PHP 8.1+）

<?php

class UserResponseDto
{
    public function __construct(
        public readonly string $id,
        public readonly string $username,
        public readonly string $email,
        public readonly string $createdAt,
    ) {}

    // Entityから変換するファクトリメソッド
    public static function fromEntity(User $user): self
    {
        return new self(
            id: $user->getId(),
            username: $user->getUsername(),
            email: $user->getEmail(),
            createdAt: $user->getCreatedAt()->format('Y-m-d H:i:s'),
        );
    }
}

3. 配列を使用した簡易的な定義

<?php

// 小規模なプロジェクトや簡単なケースでは配列も使える
function createUserDto(array $data): array
{
    return [
        'username' => $data['username'],
        'email' => $data['email'],
        'password' => $data['password'],
    ];
}

DTOのユースケースと比較

ケース1: APIレスポンスの整形

DTOを使わない場合

<?php

// Entityをそのまま返す（アンチパターン）
class UserService
{
    public function getUser(string $id): User
    {
        $user = $this->userRepository->findById($id);
        // 内部実装の詳細がそのまま露出
        return $user; // password, deletedAt, internalIdなども含まれる
    }
}

// コントローラー
$user = $userService->getUser($id);
echo json_encode($user); // passwordHashなども含まれてしまう！

問題点:

  • 不要な情報（パスワードハッシュなど）が露出
  • データベース構造の変更が即座にAPIに影響
  • セキュリティリスク

DTOを使う場合

<?php

class UserService
{
    public function getUser(string $id): UserResponseDto
    {
        $user = $this->userRepository->findById($id);
        return UserResponseDto::fromEntity($user);
    }
}

// コントローラー
$dto = $userService->getUser($id);
echo json_encode($dto); // 必要な情報のみ

メリット:

  • 必要な情報のみを公開
  • 内部実装とAPI仕様を分離
  • セキュアな設計

ケース2: バリデーションとの組み合わせ

DTOなしの場合

<?php

// バリデーションロジックが散在
function createUser(array $request): void
{
    if (empty($request['email']) || !filter_var($request['email'], FILTER_VALIDATE_EMAIL)) {
        throw new Exception('Invalid email');
    }
    if (empty($request['password']) || strlen($request['password']) < 8) {
        throw new Exception('Password too short');
    }
    // ...処理
}

DTOを使う場合（パターン1: バリデーションをDTO内に含める）

<?php

class CreateUserDto
{
    public string $username;
    public string $email;
    public string $password;

    private function __construct(string $username, string $email, string $password)
    {
        $this->username = $username;
        $this->email = $email;
        $this->password = $password;
    }

    // Factoryメソッドパターン: リクエストからDTOを生成
    public static function fromRequest(array $request): self
    {
        // バリデーション
        if (empty($request['username']) || strlen($request['username']) < 3) {
            throw new InvalidArgumentException('ユーザー名は3文字以上必要です');
        }

        if (empty($request['email']) || !filter_var($request['email'], FILTER_VALIDATE_EMAIL)) {
            throw new InvalidArgumentException('有効なメールアドレスを入力してください');
        }

        if (empty($request['password']) || strlen($request['password']) < 8) {
            throw new InvalidArgumentException('パスワードは8文字以上必要です');
        }

        return new self(
            $request['username'],
            $request['email'],
            $request['password']
        );
    }
}

// コントローラー
try {
    $dto = CreateUserDto::fromRequest($_POST);
    $userService->create($dto);
} catch (InvalidArgumentException $e) {
    echo json_encode(['error' => $e->getMessage()]);
}

DTOを使う場合（パターン2: バリデーターを分離）

<?php

// DTOはデータの保持のみ
class CreateUserDto
{
    public function __construct(
        public readonly string $username,
        public readonly string $email,
        public readonly string $password,
    ) {}
}

// バリデーションは専用クラスで実施（単一責任の原則に従う）
class CreateUserValidator
{
    public function validate(array $request): void
    {
        if (empty($request['username']) || strlen($request['username']) < 3) {
            throw new InvalidArgumentException('ユーザー名は3文字以上必要です');
        }

        if (empty($request['email']) || !filter_var($request['email'], FILTER_VALIDATE_EMAIL)) {
            throw new InvalidArgumentException('有効なメールアドレスを入力してください');
        }

        if (empty($request['password']) || strlen($request['password']) < 8) {
            throw new InvalidArgumentException('パスワードは8文字以上必要です');
        }
    }
}

// コントローラー
$validator = new CreateUserValidator();
$validator->validate($_POST);

$dto = new CreateUserDto(
    $_POST['username'],
    $_POST['email'],
    $_POST['password']
);

$userService->create($dto);

実装の選択肢:

  • パターン1（DTO内でバリデーション）: 小規模なプロジェクトやシンプルな実装に適している
  • パターン2（バリデーター分離）: 単一責任の原則（SRP）に従い、大規模プロジェクトや複雑なバリデーションに適している
  • その他の選択肢: Middlewareでのバリデーション、Form Requestクラスなど、プロジェクトの要件に応じて選択

メリット:

  • バリデーションルールが明確な場所に配置される
  • 再利用可能でテストが容易
  • 外部ライブラリに依存しない

ケース3: レイヤー間の変換

Plain Arrayを使う場合

<?php

// 各所で変換ロジックが重複
$apiUser = [
    'id' => $dbUser['user_id'],
    'name' => $dbUser['full_name'],
    'createdDate' => $dbUser['created_at']->format('Y-m-d'),
];

DTOを使う場合

<?php

class UserDto
{
    public function __construct(
        public readonly string $id,
        public readonly string $name,
        public readonly string $createdDate,
    ) {}

    public static function fromDatabase(array $dbUser): self
    {
        return new self(
            id: $dbUser['user_id'],
            name: $dbUser['full_name'],
            createdDate: $dbUser['created_at']->format('Y-m-d'),
        );
    }

    public function toDatabase(): array
    {
        return [
            'user_id' => $this->id,
            'full_name' => $this->name,
            'created_at' => new DateTime($this->createdDate),
        ];
    }
}

メリット:

  • 変換ロジックが一元化
  • 命名規則の違いを吸収
  • リファクタリングが容易

DTOを使うメリットまとめ

1. セキュリティの向上

  • 機密情報の露出を防ぐ
  • 必要最小限のデータのみを公開

2. メンテナンス性の向上

  • 内部実装とAPIインターフェースを分離
  • データベーススキーマ変更の影響を局所化

3. パフォーマンスの最適化

  • 用途に応じたデータ量の調整
  • 不要なデータの転送を削減

4. 型安全性の確保

  • PHPの型システムを最大限活用
  • IDEの補完機能で開発効率向上

5. テスタビリティの向上

  • 各レイヤーを独立してテスト可能
  • モックやスタブの作成が容易

6. ドキュメント性の向上

  • DTOの定義がそのままAPI仕様書に
  • チーム間のコミュニケーションコストを削減

さいごに

DTOパターンは、一見すると「コード量が増える」「面倒」と感じるかもしれません。しかし、プロジェクトの規模や複雑度、チーム構成に応じて適切に導入することで、メンテナンス性やセキュリティの向上といったメリットを得ることができます。

特にPHP 8.0以降の型システムの強化（Named Arguments、Readonly Properties、Attributesなど）により、DTOの実装がより簡潔で安全になりました。これらの機能を活用することで、コンパイル時（静的解析時）のチェックやIDEの補完機能による開発効率の向上という、両方のメリットを享受できます。

導入を検討すべきケース:

  • 複数人でのチーム開発
  • 外部APIとの連携が多いプロジェクト
  • セキュリティ要件が高いシステム
  • 将来的な成長が予測されるプロジェクト

慎重に検討すべきケース:

  • 小規模で成長予測がないプロジェクト
  • プロトタイプや短期間の開発
  • 単一開発者による小さなツール

DTOの導入は、プロジェクトの成長予測や要件に応じて段階的に検討することをお勧めします。必要になったタイミングでリファクタリングを行う方が、過度なオーバーエンジニアリングを避けられる場合もあります。

ぜひ、あなたのプロジェクトのコンテキストに応じて、DTOパターンの採用を検討してみてください。

参考資料

GoQSystemでは一緒に働いてくれる仲間を募集しています

ご興味がある方は以下リンクよりご確認ください。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?