ドメイン駆動設計(DDD)ってなに？第5回：DTOってなに？封筒で渡すデータという考え方

前回、ファクトリ（認証工場）を使って、安全にオブジェクトを作る話をしました。
今回は、その作ったオブジェクトを外に渡すとき、どうやって渡せばいいの？という問題です。

ドメインの中身、丸ごと渡していいの？

たとえば注文（Order）オブジェクトをそのまま外に返すと、

• 中のエンティティや値オブジェクトまでぜんぶ見える
• 意図しない操作や変更ができてしまうかも

という心配があります。

「中の人に触っちゃダメ！」って言ってたのに、出したとたんに丸裸になるみたいな感じ…

そこで登場するのが「DTO」

DTO＝Data Transfer Object。
簡単に言えば、「必要な情報だけを、わかりやすくまとめて渡すための箱」みたいなもの。

たとえ話でいうと…

ドメインの中の情報をそのままむき出しで渡すのは危険。
だから、「必要なとこだけ封筒に入れて渡す」という考え方が出てきたっぽいです。

• 「この注文の番号と金額だけを伝えたい」
• 「このユーザーの名前とステータスだけでいい」

みたいなとき、本体そのものじゃなくて、伝えたい中身だけを別の形で渡す。
それがDTOの役割。

具体的にどんな場面で使う？

• 画面に表示する用のデータを組み立てたいとき
• REST APIのレスポンスとして返すとき
• クライアント（JS側）に最低限の情報だけ渡したいとき

などなど。

ドメインオブジェクトとDTOは別物！

ドメイン側ではルールや整合性をガチガチに守ってても、
DTOは見せる・渡すための形に整え直す感じ。

たとえば：

class OrderDTO {
    public string $orderNumber;
    public string $totalPrice;
    public string $orderedAt;
}

この OrderDTO を Order から生成して、ビューやAPIで使う、という流れ。

✍️ まとめ

調べてみると、DTOっていうのは「中身を全部見せないで、必要な情報だけを封筒に入れて渡す」という考え方でした。

• いきなり本体を渡すと危ない
• でも情報は伝えたい
• だから「渡す用の形」に整えてあげる

その結果、コードの責任範囲も分かれて、使いやすくなるし事故も防げる。
なるほど、中身を守りつつ、外とやりとりするための道具ってわけですね。

次回は、例外処理の流れってどうなってるの？という疑問から、
「バケツリレー的に例外が伝わる」という話を調べてみます！

→ 続き：「例外はバケツリレー？エラー処理の考え方」に続きます！