どうも、ギルドワークス 前川です。 以前ご紹介した通り、ギルドワークスではドメイン駆動設計（DDD）の勉強会を社内で行っています。 その中で出てきた指摘に、ハッとする物があったので、今回はそれについて、ご紹介します。

「それ、ソースコードに書いてないじゃん」

それは、DDDを前提においたコードレビューで飛び出した指摘でした。

コードはかなりシンプルな、ユーザからの投稿とそれに関する感想を閲覧する、といったサービスに関するものでした。 こういった場合、当然のように、『”投稿”がトップレベルのオブジェクトにあり、それにぶら下がる形で”感想”オブジェクトがある』という様なモデル化をしていました。

一方このドメインにおいては、投稿もさることながら、投稿に対する感想の方がドメインにおける重要な関心事、なのでした。

それを話した時に、弊社増田の口から飛び出たのが、、、

「んで、それはソースコードの何処に書いてあるの？」

実装に構造を語らせるために

この時、僕は軽く衝撃を受けました。

「だって、ソースコード見てそのドメインの関心事が分からなければ、3年後見た時にわかると思う？」

…はい、分かりませんよね。そりゃあ。

そう、エヴァンスのDDD本に書いてあった、以下の一節は、そういうことを言っています。

ある種の意思決定をすることによって、モデルと実装の協調が保たれ、互いがもう一方の効果を高めるようになる。

— 『エリック・エヴァンスのドメイン駆動設計』 第二章の導入より

モデルと実装が、協調している。モデル通りの実装になっているし、実装からモデルがわかる。そのモデルというのは、ただの設計構造ではなく、顧客の関心ごとを反映した「ドメイン」である、ということ。

ではどうすればいいのか？

「それに答えなんかないですよ。色々実験してみることです。例えば、感想が重要な関心事なら 主従関係をひっくり返して、感想を投稿の親にしてみては？」

確かに、ソースコードで物を語るには、クラスの所有関係を表すのが一番です。なんとなく、理屈で収まりがいいツリー構造を考えてしまいますが、勇気を持って構造を組み替えたりして、色々実験しなければなりません。

確かに、DDDではリポジトリという形で、永続化処理をドメインから分離しています。そうすることで、永続化層の理屈をドメインから分離し、ドメインの中で腹落ちするようなモデルを構築していくのですね。

ドメインの設計を、ソフトウェアシステムにおけるその他の大量の関心事から分離することで、設計とモデルとのつながりが非常に明確になる。

— 『エリック・エヴァンスのドメイン駆動設計』 第二章の導入より

と、偉そうなことを書いていますが、私もまだまだ勉強中の身。これからも色々と実験を重ねていきたいと思います。

ギルドワークスでは、こうやってドメインのあるべき構造を追い求めてくれるような、ギルドメンバーを引き続き募集中です！興味を持たれた方は、こちらからどうぞ。