ドメイン駆動設計(DDD)ってなに？第1回：建物にたとえて考えてみた

「ドメイン駆動設計（DDD）って聞いたことはあるけど、正直よくわかってない……」

そんな自分が、あらためてDDDを学びなおしながら、ざっくり全体像を整理してみました。むずかしい話はちょっと置いといて、というわけで今回は、DDDってなに？というざっくりしたところを、自分なりに建物にたとえて整理してみたメモです。

DDDって、そもそもなに？

DDD＝Domain-Driven Design、つまり「ドメイン駆動設計」。

ドメインってなんだよって感じなんですが、ようはその業界や現場で使われてるルールや言葉のことらしいです。

DDDはそれをちゃんと設計に取り込もうよって話で、「現場の知識を、コードやクラスに落とし込んでいく」ってことらしい。

自分はどうにも概念のままだと頭に入らないので、「DDDってもし建物だったら？」というたとえで考えてみました。

1. 集約ルート＝受付窓口

どんな用件でもまずはこの窓口を通ってください！という場所。
いきなり勝手に中に入ってはいけない。ちゃんと受付を通す。
DDDでいう集約ルート（Aggregate Root）って、そういう場所みたいです。

つまり、「勝手に裏口から入らせない」ようにする。

2. ファクトリ＝認証工場

社員証を持ってる人しか入れない、ちゃんとした工場で、モノ（オブジェクト）をつくるのはここだけ。ここでは、「社員証がある人だけが入れる」「厳密なルールにそって製品がつくられる」という仕組みにするのをファクトリーと呼ぶみたいですね。

オブジェクトを適当・勝手につくることを禁止して、ファクトリ（Factory）という「ちゃんとルールにそって生成する場所」を作るルール、ということですね。

3. DTO＝封筒に入れて渡す書類

中の機密情報（ドメインモデル）をそのまま外に渡すと危険なので、必要な情報だけを封筒にまとめて渡す手法。それがDTO（データ転送オブジェクト）っていうみたいですね。

っていうのもドメインモデルって、中にすごくいろんなルールが詰まってて、できることが多くなりがち。それ故に外からそのまま使うと事故りそうだから、一度「封筒に入れて整理整頓」してから渡すのが、DTOという存在みたいです。

• ドメインモデルの中身（＝ルールや不変性）を外に漏らさない
• 外部インターフェース（APIや画面）と分離できる
• 必要な情報だけを整理して、安全に受け渡しできる

まさに「封筒に入れて、必要なとこだけ書いて渡す」という感じ。

4. ユビキタス言語＝共通の地図記号

現場・開発・営業、それぞれで言葉がバラバラだと困ります。
「これは“商品”なの？“サービス”なの？」「“締切”って何時のこと？」みたいな認識ズレが起きる。

だから「このプロジェクトでは、これをこう呼ぶよ」という共有ルールを決めておく必要があるみたいです。そのプロジェクトのルール用語辞典を「ユビキタス言語」をいうみたいですね。

結局DDDをすることでなにがいいの？

まだ全然わかりきってないけど、「ルールを決めておくことで、あとで困りにくくなる」ってことなのかもしれません。
たとえば：

• 勝手に中身を変えられない
• 誰が責任を持ってるかがハッキリする
• 役割が分かれてるので、変更に強い

そんな感じです。

まとめ

まだまだ入り口ですが、DDDの全体像が建物にたとえると少しつかめた気がします。
次回は、みんなが混乱しやすい「モデルの種類（エンティティとか値オブジェクトとか）」について、自分なりに整理してみます！

→ 続き：「エンティティと値オブジェクトで混乱した話」に続きます！
今回は以上です！