ドメイン駆動設計(DDD)ってなに？第8回：建物たとえでここまでをざっくり振り返る

DDD（ドメイン駆動設計）って、正直「名前からしてむずかしそう…」という印象が強かったんですが、自分なりに少しずつ調べながら書いてきたこのシリーズ、気づけばここまで来てしまいました。

今回は最終回として、ここまでの内容をやさしく振り返ってまとめてみたいと思います！

はじまり：「DDDってなに？」からのスタート

DDD（ドメイン駆動設計）とは：

**「現場のルールや言葉を、ちゃんと設計に取り込もう」**という考え方

最初はそれを「建物」にたとえてみました。

• 集約ルート ＝ 受付窓口
• ファクトリ ＝ 認証工場
• DTO ＝ 封筒に入れて渡す書類
• ユビキタス言語 ＝ 地図の凡例
• 例外 ＝ バケツリレー的に責任を渡すしくみ

このたとえがあることで、DDDという大きな構造の中に「人の動線」が見える気がして、
ちょっとだけ身近に感じられました。

モデルの話：「エンティティと値オブジェクトって何が違うの？」

ここが最初のつまづきポイントでした。

• エンティティ：本人であることが意味を持つ（例：社員Aさん）
• 値オブジェクト：中身が同じならどれでもいい（例：住所、金額）

さらに、「じゃあなんでも値オブジェクトにすればいいの？」という疑問に対しても、

✔ 意味のまとまりがある
✔ バリデーションなどの振る舞いがある

ときだけ切り出せばいい、というのも分かってきました。

集約と集約ルート：「このへんはセットで扱います！」という責任の範囲

• 集約（Aggregate）：目的のためにまとめたドメインの集合パーツ
• 集約ルート（Aggregate Root）：その中身を代表して管理する窓口

ここから「勝手に中身をいじらない」「外から触れるのはルートだけ」という境界意識の大切さが見えてきました。

ファクトリ：「ちゃんとした入口からしか作らせない」

ルールをすっ飛ばして new すると事故が起きる。
だから、安全な作り方を1箇所に集めるのがファクトリ（Factory）。

→ 結果として、ドメインの中身の信頼性が高まる。

DTO：「中の人をそのまま見せない」封筒みたいなもの

ドメインの中身は大事に守りたい。
でも、必要な情報は外に渡さなきゃいけない。

→ その間を取り持つのがDTO（データ転送オブジェクト）。

例外はDDDじゃないけど、責任のバケツリレーは似てるかも

例外処理はPHPの言語機能だけど、

• どこで例外を出すか（ドメインルール違反ならドメイン層）
• どこまで渡すか（アプリケーション層までで止める？UIまで？）

など、「責任を渡す／握る」という考え方は、DDDとも親和性が高いと感じました。

ユビキタス言語：「地図の凡例をそろえる」ことの大切さ

最後に登場したユビキタス言語は、ちょっと地味だけどすごく大事なやつでした。

• 現場・営業・開発の間で言葉のズレをなくす
• その言葉をコードにもそのまま使う
• 結果として、システムが現場の延長線上にあるものになる

「わかってる人同士になる」ための言葉の整理。これは、どのプロジェクトでも効きそうです。

まとめのまとめ

DDDはたしかにむずかしい概念だけど、
「設計の中にルールと責任をちゃんと埋め込む」ことが目的なんだな、と思いました。

• どこで作るか？
• どこで変更できるか？
• どこで止めるか？
• どこまで渡すか？
• どの言葉で話すか？

こういった「判断と責任」に名前をつけて設計することが、DDDなんじゃないか。
そんなふうに感じました。

ここまで読んでくれた方、本当にありがとうございました。
まだ理解はふわっとしてますが、「次にコードを書くとき、ちょっと意識してみようかな」という気持ちが少し芽生えた気がします。

今回は以上です！