ドメイン駆動設計 実践のための原則を4つ考えてみた

 『エリック・エヴァンスのドメイン駆動設計』（以下DDD本と呼ぶ）の原著出版から十数年が経過した今、DDD本に書かれている内容は、吟味されアップデートされるべき時が来ている。このアップデートに盛り込みたい内容を、4つの原則という形で考えてみた。

なお、以下では「EvansのDDD本の内容」と「ドメイン駆動設計というコンセプト」は重なる部分があるにせよ、それぞれが指す対象は異なるものだとしている。この違いは本文中で触れるが、表記として「DDD本」は本を指し、「ドメイン駆動設計」はコンセプトの方を指すようにしている。

DDD本とドメイン駆動設計

DDD本では、ドメイン駆動設計というコンセプトが導入された。ドメイン駆動設計というコンセプトは、ソフトウェアエンジニアの一般教養といえるほど、今ではその価値が認められている。同様のアイデアは、EvansがDDD本を執筆した時代ですら、すでに先人たちが口にしてきていたことだと思う。たとえそうだとしても、このコンセプトをドメイン駆動設計と名付け、著書としてまとめあげてソフトウェアエンジニア界にもたらしたことには、とても大きな価値があるだろう。

DDD本には何が書かれているのか？

DDD本に書かれている内容を、一歩ひいた立ち位置でまとめると次のようになる。

  • Evansがドメイン駆動設計というコンセプトを明に暗に思い浮かべながら、実務で取り組んだ成功／失敗エピソード 
  • Evansが自分の手持ちの技術スタック（＝オブジェクト指向分析・設計・実装）と、ドメイン駆動設計というまだ明確にはなっていないコンセプトをミックスし、実務で試す中で生まれてきた、ビジネスドメイン向けのEvans流アプローチ（モデルのビルディングブロックや、いくつかのパターン）

DDD本にはエピソードが豊富に書かれている。特に、さまざまな理由によってモデルが変化していく過程が綴られているのは特徴的だし、DDD本の面白いところでもある。個人的なお気に入りを1つ挙げるならば、深いモデルの章で紹介される船荷証券のエピソードだ。何しろ、最初の時期に考えていたモデルの要素は、最終的にはまったく不要になる話で、読めば読むほど、その最初の時期はなぜそんなことになってしまったのかというような疑問が次々と湧いてくる。Evansが言う「深いモデル」の「深さ」とは一体何なのかを考えていく契機にもなった。

DDD本に書かれているEvans流アプローチで紹介されるのは、汎用的な概念・パターンが多い。これらは一見すると、さまざまなドメインに対して適用可能に思える。エンティティやリポジトリといったパターンを使い、ある程度うまく機能するシステムを作れるケースは、現在でも多くある。また、仕様パターンの提案や、仕様パターンをリポジトリやファクトリと協調させる設計などは、形はそのままでは無いにせよ、アイデアとしては今でも有用だ。このように、Evans流アプローチにも学びどころはある。

しかし、ビジネスドメインに的を絞っても、Evans流アプローチには弱い点がある。その弱点をこの記事では趣旨とだいぶズレてしまうため述べないが、Evans流に一点張りするのは危険だということだけ触れておく。

DDD本には何が書かれていないのか？

DDD本を、ドメイン駆動設計のコンセプトを的確に伝えるための書物として見た場合、率直に言って重要なことが書かれておらず、適切ではない。重要だが書かれていないことがあるのだ。

DDD本ではドメイン駆動設計というコンセプトに対して、その1つの実現形態であるEvans流のモデリングと設計のエピソードがパターン形式で綴られている。しかし、これだけがドメイン駆動設計に当てはまる手法というわけではない。

どんなアプローチも万能ではなく、必ず射程が存在する。Evans流アプローチの射程は、贔屓目にいってもビジネスドメインであり、SoR（記録系のシステム）ドメインであり、また、エンティティを中心に形作られるドメインだろう。

世の中には、これに当てはまらないドメインが多数ある。また、無理に当てはめると機能しないシステムができあがってしまうようなドメインも多数ある。グラフの探索機能や行列計算ライブラリ、機械学習のためのフレームワークなどは、エンティティやリポジトリ、値オブジェクトといったパターンを単純に当てはめることが難しかったり、無理に当てはめると失敗しそうなドメインとして分かりやすい。

このようなドメインに取り組む場合でも、ドメイン駆動設計というコンセプトは役立つはずだ。ドメイン駆動設計というコンセプトは、あらゆるドメインの問題に取り組む際に有用だからだ。しかし、このようなコンセプトの本質的な内容を知りたくても、DDD本に書かれているエピソードからは、フワフワした輪郭としてしか浮かび上がってこない。DDD本には明確には述べられていないのだ。

まとめると、次の2つが明確な形では書かれていないことになる。

  • ドメイン駆動設計というコンセプト
  • ドメイン駆動設計というコンセプトと、その1つの実現形態であるEvans流アプローチとの関係性およびその位置づけ

この2つの欠点を補うようなアップデートがDDD本になされるか、または新たな書籍が執筆されるべき時だと思う。そんなささやかな期待を持ちつつ、私はこの記事で、DDD本の2つの欠点を補う内容を4つの原則にあらわしてみた。 

どうすればドメイン駆動設計を学べるのか？

核心を述べよう。どうすればドメイン駆動設計を学べるのか？ この問いに対する私の答えは「ドメイン駆動設計を学ぼうとするな。ドメインについて学べ。」だ。多くの先人達も同じことを言われている。私はこのことをもっと強調したい。これは、ドメイン駆動設計を学ぶ際に必ず心にとめておかなければならない原則なのだ。

ドメイン駆動設計を学ぶ際に心にとめておく原則

ドメインについて学ぶ ＞ ドメイン駆動設計を学ぶ

ドメイン駆動設計というコンセプトは、詰まるところ設計技法そのものではない。これについては、twitterでsugimoto_kei氏の次のtweetでも言われている。

ドメイン駆動設計について学ぶな、DDD本を読むな、とまで言うつもりはない。 しかし、ドメイン駆動設計というコンセプトで表される設計活動を学んで実践し会得するには、実際にドメインの問題と向き合って格闘するのが一番なのだ。それ以外に身につける方法はないとも言える。それに加え、自分が向き合っているドメインの問題は、どのように分析できるのか、どのようにモデル化できるのか、どんな設計が使えるか、、、こういったことを考えるヒントは、DDD本にしかないわけではない。むしろDDD本から離れて、そのドメインに向き合った先人たちの考えたことを素直に参考にした方がよい場合が多い（もちろん、技術の進歩というエッセンスは自分で加える必要があることは言うまでもない）。そうして、ドメインの問題の解決に没頭することが、ドメイン駆動設計であるとも言える。

DDD本に書いてあるEvansのエピソードは、そんな没頭の合間に、自分の向いている目線を確かめ、気持ちを再びドメインに引き戻すためのリフレッシュ材料として読めばよいのだ。

しかし、これだけでは結局「ドメイン駆動設計」というコンセプトが何なのか分からない。「ドメインに向き合っていれば自然と身につく」なんて言われても、その経験がないうちに納得できるはずがないし、「間違ったドメイン駆動設計」が存在し得ないようなら、コンセプトとして持ち出す意義も納得できない。ドメイン駆動設計のコンセプトを、日々の活動レベルで使っていくためには、実践者が自分の進む方向を自ら見出していけるような、分かりやすい指針があるとよい。これを3つの原則として表してみた。

ドメインモデルに取り組むハート

 ドメインモデルに取り組むハートの3原則

1. ドメインモデルとは、開発者＝設計者が創り出すものだ

2. ドメインの問題にウェイトを置こう

3. ドメインを見る目、解決策を見る目を養おう

ドメインモデルは、開発者＝設計者が自ら創り出すもの、というのが私の考えだ。設計は、大なり小なり何らかの解決の仕組みを創り出すプロセスであって、そこにクリエイティブなマインドは欠かせない。ドメイン駆動設計では、このクリエイティブ・マインドを、ドメインモデルにおいて発揮することになる。ドメインモデルのモデリングと設計は、外から与えられた要件をなぞるだけの行為ではないのだ。 

そして、ドメインモデルにクリエイティブに取り組む際、設計者の先入観が邪魔になることがある。どういうことか。開発者＝設計者は、問題を理解するためのスタート地点として、必然的に「手持ちの技術」 で捉えようとしてしまう。その「手持ちの技術」は自分の手足のような存在、さらに言えば空気のような存在なので、あえてそれを使っているとは意識しない。問題のスタートから少しでも理解が進んで何らかの形が見え始めると、空気として存在している手持ちの技術が、その問題の解決に適しているのかを疑おうとしなくなってしまうのだ。

しかし、大事なのは、ドメインの問題をより上手く解決することだ。これを達成するためには、理解が進んで出来上がってきた形を疑うことだけでなく、ときには最初に用意した手持ちの技術さえ疑ってみる必要がある。この疑いは、慣れていないととても苦しい行為だ。なぜなら、自分自身のスキルや成果を否定するように感じるからだ。だが、ドメインの問題を解決することにウェイトを置くという共通理解があれば、余計な不安を抱えることもなくなる。自信を持ってスタート地点のはしごを外せるようになる。それに加え、自分にはまだ未知の技術だとしても、ドメインの問題をより上手く解決しそうだと客観的に判断できれば、学んで採用していける。

このようなドメインモデルに対する取り組みでは、開発者＝設計者の「ドメインを見る目」を育てなければならないが、それと同時に、あらためて「解決策＝技術を見る目」も育てなければならない。この2つの目は、ドメインに取り組む開発者にとって、どちらも欠かせない両輪なのだ。

ドメインの問題をより上手く解決するという基準に立つと、この２つの目が常に問われ続ける。その目の中には、ドメインの問題に適合するかどうかを判断するための論理力や、必要な時に必要なことを学んで取り入れていける柔軟性も含まれる。とてもハードルが高く聞こえるかもしれないが、これらの技術は、ソフトウェアエンジニアにとって普遍的に役立つ。 

さいごに

ここに述べた4つの原則が、私が『エリック・エヴァンスのドメイン駆動設計』から学んで得たことだ。もちろん、DDD本だけからこのような理解が得られたわけではない。多くの本を読み、先輩方や仲間との議論や対話、さまざまな試行錯誤の結果として得られたものだ。このような経験は私にとっては言葉にできないほど有益だったが、これだけの労力と時間を世の中の多くのエンジニアに強いるのは、良いことではない。ドメイン駆動設計のコンセプトの伝え方、そして何よりドメイン駆動設計というコンセプト自体は、今後もっと洗練されるべきだろう。そうすれば、ドメイン駆動設計のコンセプトが薄れるのではなく、蒸留されたエッセンスとして後世に伝わっていく。

この4つの原則が、今この瞬間にも生まれてくるドメインの問題を上手く解決するモデルを創り出す一助に（間接的にでも）なれば幸いだ。