この本を通して、DDDについて多くの言葉が登場しました。

  • Entity
  • Value Object
  • Repository
  • UseCase
  • 境界
  • モデル
  • 共通言語

しかし、ここで一度立ち止まって確認したいことがあります。

この本が本当に伝えたかったのは、

これらの言葉そのものではない

という点です。

最終章では、これまでの内容を振り返りながら、 DDDとどう付き合っていくとよいのかを、改めて整理します。

DDDは「正解集」ではなかった

第一章から一貫して述べてきた通り、DDDは

  • 正解を与える設計論
  • そのまま使える設計テンプレート

ではありません。

むしろDDDは、

設計について考え続けるための視点の集合

です。

  • なぜここに置いたのか
  • なぜこの責務は重く感じるのか
  • なぜこの変更が怖いのか

そうした問いを、 曖昧な感覚のままにせず、 言葉として扱えるようにする。

それがDDDの本質でした。

モデルとは「ルールを閉じ込める場所」だった

本書では何度も、

  • EntityかVOか
  • どこからモデルにするか

という話題が出てきました。

しかし、結論はとてもシンプルです。

モデルとは、守りたいルールを閉じ込めるための器

です。

  • 変わってほしくない振る舞い
  • 破られると困る制約
  • 他の場所に漏れると危険な判断

それらが見え始めたとき、 初めてモデルは意味を持ちます。

最初から立派なモデルを作る必要はありません。

必要になったときに、必要な分だけ導入する

それが、実務に耐えるDDDでした。

Repositoryは「境界の翻訳者」だった

Repositoryについても、

  • 薄くするべきか
  • ロジックを持つべきか

といった議論を扱いました。

ここで大切なのは、

Repositoryはドメインと技術の境界に立つ存在

だという点です。

  • UseCase側にはドメインの言葉がある
  • 実装側にはDBやAPIの都合がある

Repositoryは、その両者を

お互いに汚染させないための翻訳層

として機能します。

「薄い／厚い」という言葉に引きずられるよりも、

  • どこまでをドメインとして守りたいか
  • どこからを技術的詳細として隔離したいか

を考えることの方が重要でした。

DDDは「チームで悩むための言語」だった

DDDは、 個人の設計力を高めるだけのものではありません。

むしろ、

チームで設計について悩むための言語

として使われたとき、 最も効果を発揮します。

  • 何がつらいのか
  • どこが壊れやすいのか
  • なぜこの変更が怖いのか

こうした感覚を、

  • 境界
  • 責務
  • モデル

といった言葉で共有できるようになる。

DDDが提供する価値は、

結論を揃えることではなく、 悩み方を揃えること

でした。

DDDは「使わない判断」も含んでいる

この本では、 あえて次のことも強調してきました。

  • すべてにDDDを適用しない
  • 単純なものは単純に書く
  • 途中でやめる判断を恐れない

DDDは、

設計を複雑にするための理論ではありません

変更を楽にするための手段です。

もしDDDを使った結果、

  • 読みにくくなった
  • 触りにくくなった
  • 説明が難しくなった

のであれば、 それは立ち止まるサインです。

DDDから離れる勇気もまた、 DDDを理解した結果なのです。

おわりに

ここまで、DDDという言葉を手がかりに、 設計について考えてきました。

この文章は何かを結論づけるために 書いたものではありません。

設計に向き合う中で感じた違和感や迷いを、 そのままにせず、 一度立ち止まって言葉にしてみる。

DDDは、そのための 一つの枠組みとして存在すると考えています。

設計は、 時間とともに変わります。

コードも、 要求も、 チームも変わり続けます。

その中で、

  • 何を守ろうとしたのか
  • なぜこの形を選んだのか

を思い出せる手がかりが、 どこかに残っていることは、 きっと無駄にはなりません。

この文章もまた、 そうした手がかりの一つとして残します。