DTOの使い分けってどうするの？新人エンジニアのための「全部入りDTO」運用ガイド
山崎講師
こんにちは。ゆうせいです。
今回は、新人エンジニアの方からよく聞かれる疑問にお答えします。
「すべてのフィールドを持ったDTOを作って、あとは表示側で取捨選択するってアリですか？」
実はこれ、現場でもかなりよくある運用方法なんです。ただ、メリットもあれば注意点もあります。
それでは一緒に、じっくり見ていきましょう！
DTOって何だっけ？
まずは前提の確認から始めましょう。
DTO（Data Transfer Object）とは、名前の通り「データを運ぶための入れ物」です。
たとえばWebアプリケーションでは、DBやサービス層から取得したデータを画面表示やAPIレスポンス用に整形するために使います。
例えるなら、DTOは「お弁当箱」です。
ご飯（顧客名）も、唐揚げ（車名）も、ブロッコリー（購入日）も、詰めて渡す感じですね。
すべてのフィールドを持ったDTOとは？
こんな形のDTOをイメージしてください
public class CarSaleFullDto {
private int customerId;
private String customerName;
private String email;
private String phone;
private int carId;
private String carName;
private double price;
private String color;
private int saleId;
private Date saleDate;
private String paymentMethod;
private boolean delivered;
}
これは「顧客・車・販売情報」すべてを一つに詰め込んだDTOです。
まさに全部入りですね。
表示側で必要な項目だけ使うスタイル
使い方としてはこんな感じです：
System.out.println("顧客名: " + dto.getCustomerName());
System.out.println("車名: " + dto.getCarName());
System.out.println("購入日: " + dto.getSaleDate());
// email や 支払い方法は表示しない
使う側が選ぶという運用ですね。
この方法のメリットとデメリット
メリット（いいところ）
| メリット | 説明 |
|---|---|
| DTOが増えすぎない | 画面やAPIごとにDTOを作らなくて済むので、クラス数が抑えられる |
| ロジック共通化がしやすい | Excel出力やログ出力など、共通処理に使いやすい |
| 開発が早い | ひとまず全項目が揃っているので、個別にDTOを作る手間が省ける |
たとえば、「とりあえず全部まとめて返しておいて、必要なものだけ使おう」というスタートアップ開発では、とても重宝されます。
デメリット（気をつけたいところ）
| デメリット | 説明 |
|---|---|
| DTOが肥大化する | 本来関係ない項目まで含まれていて読みづらい |
| 意図がわからない | 画面やAPIに「なんでこの項目あるの？」という疑問が出やすい |
| セキュリティリスク | 表示してはいけない項目（例：メールアドレスなど）も含まれてしまう可能性 |
| 関心の分離（SoC）が崩れる | 特定の処理のためだけの情報が混ざることで、役割が曖昧になる |
これは「何でも入ってる便利なバッグ」みたいなもので、使い方次第でカオスになります。
解決策：使い分けよう！フルDTOと用途別DTO
では、どうすればバランスよく運用できるでしょうか？
内部処理用と表示用を分けて使うのがベストです！
推奨パターン
| 用途 | DTOの種類 | 備考 |
|---|---|---|
| DBアクセス・共通処理 | フルDTO（全部入り） | CSV出力、ログ用など内部用途に最適 |
| 画面表示・APIレスポンス | 軽量DTO（必要項目だけ） | 関心の分離を守り、安全性も向上 |
マッピングの自動化でラクしよう！
「DTO分けるの面倒じゃないの？」と思うかもしれません。
そんなときは、マッピングライブラリを使いましょう！
代表例：MapStruct（Spring Bootで人気）
@Mapping(target = "carName", source = "carName")
CarSaleListItemDto toListItemDto(CarSaleFullDto fullDto);
フルDTOから必要な項目だけ詰め替えるのを、自動でやってくれます。
IDE補完も効くので、ミスも防げて安心です。
まとめ：DTOの使い分けはプロの第一歩！
「全部入りDTOを作って、表示側で取捨選択する」方法は、十分アリです。
ただし、本番運用にはリスクもあるので、次のように使い分けるのがおすすめです。
- フルDTOは内部処理・共通処理で使う
- 表示やAPIレスポンスには用途別DTOを使う
- MapStructなどのマッピングツールで手間を減らす
今後の学習の指針
DTO設計は、次のステップでより深く学べます。
- 関心の分離（SoC）の原則について学ぶ
- MapStructやModelMapperの使い方を習得する
- セキュリティ設計とDTOの関係を意識する
- REST APIの設計原則に沿ってDTOを分けてみる
ぜひ、DTOの設計力を武器に「読みやすく、安全で拡張しやすいコード」を目指していきましょう！
何かあれば、また気軽に聞いてくださいね。
セイ・コンサルティング・グループの新人エンジニア研修のメニューへのリンク
投稿者プロフィール
- 代表取締役
-
セイ・コンサルティング・グループ株式会社代表取締役。
岐阜県出身。
2000年創業、2004年会社設立。
IT企業向け人材育成研修歴業界歴20年以上。
すべての無駄を省いた費用対効果の高い「筋肉質」な研修を提供します！
この記事に間違い等ありましたらぜひお知らせください。
