さあ、モデルの話をしよう 〜Liteにはじめるドメイン駆動設計〜

ドメイン駆動設計に興味を持ったとき、私たちの前にはさまざまな設計パターンに関する情報が現れます。なかでも、「エンティティ」「値オブジェクト」「アグリゲート」「リポジトリ」といったパターンは明快で導入しやすいため、実装に取り入れてみている人も多いことでしょう。

かつて私も、軽量DDDのような取り組みに惹かれ、“実装の形式を守ることこそがドメイン駆動設計だ”と信じていました。しかし、その姿勢に違和感を覚えるようになり、やがて、設計の対象について明確なメンタルモデルを持つことの方が、実はずっと大切なのだと気がつきました。

「私たちは、どのように世界を理解し、どのような物語を編むのか？」

本稿では、ドメイン駆動設計の本質を改めて見つめ直し、そこから最初の実践へと踏み出す第一歩を考えてみたいと思います。

第１章：誤解を紐解く

「エンティティ」「値オブジェクト」「アグリゲート」「リポジトリ」など、すぐに取り入れられそうに見えるそれらのパターンは、ドメイン駆動設計の入り口として親しまれてきました。しかし、その取り入れやすさは私たちの理解を行き詰まらせてしまうこともあります。

まずは、私たちが陥りやすい誤解や誤用、“できているつもりのドメイン駆動設計”について顧みてみようと思います。見過ごしてきた違和感に向き合うことから始めていきましょう。

『エリック・エヴァンスのドメイン駆動設計』

ドメイン駆動設計という言葉を聞くとき、私たちはしばしば、設計パターンや設計技法に関する豊富な知識を思い浮かべます。その中には、ソフトウェアの複雑さに立ち向かうための実践的な考え方や手法が数多く含まれています。こうした知識は、ドメイン駆動設計を学び始めた人々にとって大きな魅力であり、しかしまた同時に、少し圧倒されるものでもあります。

実際、『エリック・エヴァンスのドメイン駆動設計』は、数多くのパターンとそれらの関係性を丁寧に書き綴った、まさに設計とプラクティスのパターンカタログとも呼べる一冊です^[1]。日本語訳の帯には「ユーザ要求の問題解決にフォーカスした設計パターン」と銘打っています。

それではまず、パターンとは何かについて、少し振り返ってみることにしましょう。

パターン（パターン・ランゲージ）

ドメイン駆動設計に対する誤解を紐解いていくために、まずは「パターン」とは何かについて目を向けてみます。

パターンはもともと建築の分野で発展してきたものです。特に有名なのは、建築家クリストファー・アレグザンダーが提唱した「パターン・ランゲージ」という考え方です。そこでは、人々の暮らしや営みの中に繰り返し現れる「よいかたち」を見出だし、それを言語（ランゲージ）として共有することで、実践知やセンスを伝えようとしています^[2]。

ソフトウェア開発におけるパターンも同じです。先人たちが典型的な設計をまとめた結果であり、それを再利用できる形にした知識がパターンなのです^[3]。

ここで、パターンの意義を誤解すると、私たちは本来の意図とは異なるかたちでドメイン駆動設計を捉えてしまうかもしれません。次に、パターンの誤用について考えてみましょう。

「アーキテクチャ」とは何でしょうか。

「アーキテクチャ」もまた建築由来の言葉で、全体がどうまとまっているか、その構造や設計法工法を含めた全体を意味する言葉です。対象物を特徴づける様式のことで、材料・方法・フォームを含むスタイルであり、文化・思想・価値観を反映した表現でもあります。

パターンが「個々の局所的な問題の解決」であるのに対して、アーキテクチャは「全体の構造や骨格」あるいはその「文化的背景や思想」を指します。

ただし、構造全体を問題にするとき、アーキテクチャもまたアーキテクチャパターン（典型的な骨格とその導出パターン）として扱われます。

パターンの誤用

パターン同士には、類似関係や利用関係といったつながりがありますが、それらをどう利用して問題を解決するかの方針は、文脈やフォース（その問題が発生してしまう理由やその解決を有効だと考える理由）によって変わってきます。パターンの利用者、つまり読者である私たちは、その時々の状況に応じて、適切なパターンを選び、組み合わせて用いることが求められます。パターンとは、あらゆる場面で一律に適用できる「規則」なのではなく、むしろ判断と理解を支える「思考の道具」なのです^[4]。

「エンティティ」「値オブジェクト」「アグリゲート」「リポジトリ」などのパターンはそれ単体で導入しやすいこともあり、実装に取り入れている人、あるいはチームも、多いことでしょう。私もかつては“エンティティやリポジトリを使えばそれだけでドメイン駆動設計になる”と考えていました。いわゆる軽量DDDと呼ばれる取り組みは、そうした実装レベルでのアプローチ、つまり、パターンを実装スタイルとして導入しようとする姿勢を指しているように思えます。

しかし、ここで直面するのは次のような諸問題です。

• アグリゲートを設けたものの、責務が曖昧で単なるデータコンテナになってしまった
• あるいは多様なユースケースに応じるため、逆に責務が大きくなり過ぎてしまった
• リポジトリは作ったが、データのマッピングの多さに悩まされている
• 値オブジェクトを導入したのに、結局はただのラップクラスにしかならなかった

こうしたつまずきの原因は、形式を守ることで設計を駆動してしまうことにあります。たとえ『エリック・エヴァンスのドメイン駆動設計』にある数々のパターンを導入したことで“実装がそれらしく整っている”ように見えたとしても、それが形式で成り立っているのであれば、その設計がドメインに根ざしているとは言えません。

パターンだけを実践しようとすることは、このような誤解そのものです。パターンがあくまで「手段」であり「目的」ではないことを、私たちは見失ってしまっていたのです。

では、その目的とは何なのでしょうか。ここで、私たちはそもそも「何を表現したかったのか？」ということが明確でなかったことに、改めて気づかされます。

ドメイン駆動設計に関する議論を眺めてみると、「イミュータブルな値オブジェクトにしなければならない」「集約はカプセル化されていなければならない」などのように、技術的なプラクティスが強調されることが少なくありません。

軽量DDDやボトムアップDDDなど、戦術的設計と総称される設計パターンを重視する傾向は、日本で特に顕著であるように感じます。

英語圏の記事や議論を覗いてみると、「BC」という単語が頻繁に登場することからも、Bonded ContextやContext Mapなどが議論の中心に据えられている印象を受けます。

第２章：真意を読み解く

ここからは、「ドメイン駆動設計」とは何なのか、そしてどのように実践へとつなげていけるのか、私なりの解釈を交えながら、その本質を捉え直してみたいと思います。

ドメイン駆動設計

ドメイン駆動設計とは何か。この問いへの答えは、『エリック・エヴァンスのドメイン駆動設計』の「まえがき」にあります。

そこでは、「ドメイン駆動設計」とは、ドメインモデリングと設計をどのように行うかを追求する哲学であると述べられています^[5]。つまり、ドメイン駆動設計とは単なる技法の集合ではなく、私たちがソフトウェアの設計において「何を大切にするのか」「どこに目を向けるのか」といった態度そのものに関わるものなのです。

ドメインモデリングと設計の哲学

ここでいう哲学とは、ある問題の「本質」を明らかにすることで、その問題を解き明かすための「考え方」を見出だす営み^[6]──そう捉えるのがよいでしょう。

『エリック・エヴァンスのドメイン駆動設計』で語られる哲学とは、単なる設計技法の集まりではなく、設計そのものへの向き合い方を問うものです。それは、継続的な対話と探究の姿勢、すなわち、対話と新たな洞察を通じてモデルを育て、そのモデルをコードにおいて表現しようとする考え方です。

こうした姿勢は、設計や実装を単なる構築作業ではなく、コミュニケーションの一形態として捉え直すことにつながります。私たちがコードに表現しようとするモデルが、ドメインについて語るための言語となり、チームのコミュニケーションを豊かにしてくれる。それこそが、ドメイン駆動設計を実践するということなのです。

ユビキタス言語とモデル駆動設計

『エリック・エヴァンスのドメイン駆動設計』の見返し（表紙と裏表紙の内側に貼り付けられた色紙）には、この本で述べられていることの全体像を表す象徴的な図が描かれています。この図からは、ふたつのパターンを軸に据えていることが読み取れます。それは「ユビキタス言語」と「モデル駆動設計」です。

『エリック・エヴァンスのドメイン駆動設計』見返し（表紙側）

『エリック・エヴァンスのドメイン駆動設計』見返し（裏表紙側）

「ユビキタス言語」とは、開発者とドメインエキスパートのあいだにある分断を、共通の言葉によって橋渡ししようとする試みです。ドメインエキスパートにも理解できる言葉で設計を支え、両者のあいだで通訳を介することなく、共有された概念としてのモデルを築こうとします。

モデルはユビキタス言語の骨格であり、言語の変化はモデルそのものへの変化と等しく扱われます。つまり、それは単なる用語集ではなく、ドメインへの理解を深め、それを共有していくための言語──それをチームで育み、モデルに対する洞察を深めていく営みなのです。

そしてもう一方の「モデル駆動設計」とは、アルゴリズム的な詳細よりもモデルを第一に考え、モデルの構築と活用を中心に据える開発のアプローチです^[7]。コードをモデルに近づけることで、コードに意味を与え、ソフトウェアの設計に一貫性と確かさがもたらされます。

コードの変更は、すなわちモデルの変更でもありうるため、設計や実装の中で得られた洞察は、ユビキタス言語を通じてモデルへと反映されていきます。こうした過程は、ソフトウェアの設計の中核であるモデルを、ユーザーに対しても明確に開示することにつながります。モデルが明らかになれば、ソフトウェアはユーザーにとって予測可能で一貫した道具となり、その潜在的な力を十全に引き出せるようになります。

「ユビキタス言語」と「モデル駆動設計」は、対話と思考の枠組みであり、設計を支える土台となります。どちらか一方では不十分であり、両者が交わるところにこそ、ドメイン駆動設計の実践は息づいていきます。そして、そこに築かれるのが、私たちのモデルなのです。

「ユビキタス言語」や「モデル駆動設計」から一歩進んで、他にはどのようなパターンがあるのでしょうか。一般的には「戦略的設計」「戦術的設計」と呼ばれるものですが、ここでは少し違った視点から捉えてみたいと思います。

たとえば、「構成要素」や「しなやかな設計」は、モデルそのものの性質──つまり、モデルの内在的な側面を扱ったパターンです。

一方、「コンテキスト」「蒸留」「大規模な構造」などは、モデルが置かれている環境や他のモデルとの関係──つまり、外在的な側面に目を向けたパターンです。

「戦術」「戦略」というラベルよりも、モデルを中心とした「内と外」という視点で捉え直してみることで、それぞれのパターンが示す意味が身近に感じられるかもしれません。

モデル（メンタルモデル）

モデルとは、単なる構造や振る舞いの定義ではありません。私たちが現実のドメインをどのように捉え、どのように意味づけているか──つまり、メンタルモデルとしての性質を持っています。モデルを構築することは、現実を抽出することではなく、現実への理解を組み立てていくことにほかなりません。

ユビキタス言語は、そうした理解を育てるための対話の場をつくります。開発者とドメインエキスパートが言葉を交わし、互いの認識を調整しながら、共通のモデルを形作っていく。そこには、“正しいモデル”が最初から存在するのではなく、理解が深まるごとにモデルもまた進化させていくという姿勢が求められます。

ユビキタス言語による対話を通じて生まれた理解を、モデルとして構築し、評価し、必要に応じて再構成していく。この繰り返しのなかで、設計は進化し続けます。モデルは静的な設計図ではなく、対話と実践の中で生きた意味をもつ動的な存在です。モデリングとは、単に形を与える行為ではなく、言葉と理解とを手がかりにして、共通の認識を育てていくプロセスなのです。

モデリング（エコシステム）

モデルとは、チームの中で共有される共通の理解、すなわちメンタルモデルである──この前提に立つとき、それはもはや個人の頭の中に完結するものではなくなります。モデルは、関係する人々の間で交わされる言葉、行動、経験の中で共有され、育まれていきます。

モデリングという営みは、単なる思考や図解の手続きではなく、ひとつのエコシステム（生態系）­として捉えることができます。そこには、モデルを生み出し、問い直し、育てていく構成要素があり、それらが有機的に関係し合いながら、絶えず変化と進化を繰り返していきます。

このエコシステムの中核にあるのは、「人」と「言語」、そして「コードによる実装」です。ユビキタス言語によって結ばれた人々が、日々の対話と協働の中で理解を深め、コードに反映し、そこから得られた経験や失敗を再び言語とモデルに還元していく。こうした循環が、モデリングのダイナミクス（生命）を支えているわけです。

このようなエコシステムがうまく機能しているとき、チームは単なる「仕様の実装」以上のことを行っています。私たちは、共有された世界観に基づくソフトウェアの創造という、知的で創造的な営みに取り組んでいるのです。

歴史学の分野で、モデリングは次のようなプロセスで進められるそうです^[8]:

• 出土品などの資料から仮説を立て、検証する
• 当時の姿を再現するためのモデルを構築する
• 新たな発見があれば、それを踏まえてモデルを再構成する

ひとつの小さな発見によって、既存のモデルが根底から書き換えられることもあります。これは『エリック・エヴァンスのドメイン駆動設計』における「ブレイクスルーの話」に、まさに通じるものがあります。

第３章：Liteにはじめる

ドメイン駆動設計を始めようとするとき、すべてのパターンを正しく使おうとしたり、複雑な仕組みを先回りして整えようとしたりしがちです。しかし実際には、もっと小さなところから始められます。

モデルを仮説し、それを表に出して、力のかけどころを選ぶ。ここからは、そうしたシンプルな試みによって、ドメインモデリングと設計にどのように向き合っていけるかを考えていきます。

メンタルモデルを仮説する

ドメイン駆動設計はチームの知を育む営みでもありますが、その出発点は往々にして個人の中にあります。最初からユビキタス言語があるわけでも、完成されたモデルが手元にあるわけでもありません。手探りのなかで、現実をどのように捉えればよいのかを模索することから始まります。

ここで必要なのは、「問題領域を分析すること」に留まらず「ドメインの問題をどう解決しようとするか」にフォーカスした理解、すなわち仮説としてのメンタルモデルです。情報および情報処理をいかに構成すれば、課題をうまく解消できるか──それこそがモデルなのです^[9]。

モデルは、オブジェクトモデルであってもいいし、データモデル、プロセスモデル、あるいはその折衷であってもいいかもしれません。大切なのは、それが自分の中にある問題解決のイメージであり、他者に伝えるための足場となっているかどうかです。

このようなモデルは、最初は正確なものではないかもしれません。むしろ、あいまいで、間違っていて、偏っていてもいいのです。なぜなら、モデルを仮説することは、それを評価し、他者との対話を通じて更新し続ける前提に立つということだからです。

言葉にする、図にする、コードにする、そのどれもがメンタルモデルを外に取り出し、検討の俎上に載せるための手段です。そして、モデルは自分の頭の中にだけあるものではなくなり、対話と思考を育む土壌になっていきます。

モデルを表に出して対話する

仮説したメンタルモデルは、まずは自分の手で確かめてみることが大切です。たとえば、モデルに登場する構成要素を動かしてみたり、典型的なケースや例外的な振る舞いをなぞってみたりする。そうしたシミュレーションによって、思いがけない矛盾や曖昧さに気がつくこともあります。

また、過去にあった経緯や判断、似たような問題にどう向き合ってきたかといった意思決定の履歴も、モデルをかたちづくる重要な材料になります。それらはモデルの妥当性を測る手がかりになるかもしれません。あるいは新たな視点を与えてくれる触媒になるかもしれません。

そして、そのモデルを外に出してみること。言葉にしたり、図にしたり、ときにコードとして表現してみたりする。そうすることで、モデルは他者の目に触れる可能性を持ち始めます。そこから、誰かとの対話が始まるかもしれません。

「なるほど、そういうふうに捉えられるのか」「それって、前に挙がったこの話題に関係しそう」そんなやりとりのきっかけになれば、モデルはもはや一人のものではありません。 対話の中で違和感をすり合わせ、時には前提から問い直してみる。解像度を高めながら、チームのあいだに共通の理解を根づかせていきます。

本当に譲れないものを選ぶ

理想的なモデルを描こうとしても、現実にはさまざまな制約があります。納期、リソース、技術的な都合、あるいは周囲の理解や期待。すべてが完璧である環境は、まずありません。

だからこそ、私たちは「今できる範囲で、何を実現することに最も価値があるのか」を常に問い続けなければなりません。その時その状況で、モデルにどこまでの期待を託すのか、そのラインを見極めていく必要があります。

パターンを盲信するのではなく、目の前の文脈や状況を見つめ、注力すべき点を見定める。それが、現実的で誠実なアプローチです。

設計とは、取捨選択の連続です。全部を盛り込まないこと、すべてをうまくやろうとし過ぎないこと。むしろ、「本当に譲れないもの」を見極め、それを守り抜くための選択を重ねていく――その姿勢が、ソフトウェアが大切にするものを浮き彫りにするでしょう。

おわりに

ドメイン駆動設計という言葉に触れたとき、私たちはつい、その技法やパターンのすべてを理解し、正しく使いこなさなければならないような気持ちになります。

しかし、その本質はもっと別のところにあります。設計の対象について、自分なりの見立てを持つこと。モデルに手をかけ、言葉をかわし、チームのあいだで理解を育てていくこと。

それは、特別な技術や道具に頼らずとも始められる、対話と思考の営みです。制約が避けられない現場においてこそ、仮説し、すり合わせ、選択するという設計の基本が問われます。

パターンを使うために設計があるのではなく、意味のある設計のためにパターンを使う。その順序を見失わなければ、どんな小さな実践もドメイン駆動設計の地続きにあると、私は思います。

脚注

1. 佐藤匡剛. “[ 技術講座 ] Domain-Driven Designのエッセンス 第1回”. オブジェクトの広場. 2007-07. https://www.ogis-ri.co.jp/otc/hiroba/technical/DDDEssence/chap1.html, (参照 2025-05-01).

2. CreativeShift. “パターン・ランゲージとは”. クリエイティブシフト. 2020-09-05. https://creativeshift.co.jp/pattern-lang/, (参照 2025-05-01).

3. 鷲崎弘宜. ソフトウェアパターン概観. 情報処理, 情報処理学会. 2011, Vol.52, No.9, 1119-1126

4. ryoasai. “日本でパターンが広まらない理由の一つは「ワンパターン」などのネガティブな和製英語のせい？”. 達人プログラマーを目指して. 2011-08-21. https://ryoasai.hatenadiary.org/entry/20110821/1313927820, (参照 2025-05-01).

5. エリック・エヴァンス. エリック・エヴァンスのドメイン駆動設計. 株式会社翔泳社, 2011, 576.

6. 苫野一徳. “第1回　哲学ってなんだ？”. webちくま（筑摩書房の読みものサイト）. 2016-04-11. https://www.webchikuma.com/n/n228e480e3733, (参照 2025-05-01)

7. “モデル駆動工学”. ウィキペディア (Wikipedia): フリー百科事典, 2019-12-27 06:27, https://ja.wikipedia.org/wiki/モデル駆動工学, (参照 2025-05-01).

8. 澁川喜規. “ドメイン駆動設計の源流のPofEAAを読んでみる”. フューチャー技術ブログ, 2022-06-09, https://future-architect.github.io/articles/20220610a/, (参照 2025-05-01).

9. 杉本啓. “杉本 啓「2つのドメインモデル―DDDの含意」”. PHP Mentors, 2015-12-20, https://phpmentors.jp/post/136939446193/two-domain-models-implication-of-ddd-ja, (参照 2025-05-01).