最近、ソフトウェア開発を行っているので、ソフトウェア設計に関する勉強をしている。
「エリック・エヴァンスのドメイン駆動設計」を読んだので、内容をまとめた。
以下の内容は、ほとんどClaude3 Opusで書いている。
概要
第1部 ドメインモデルを機能させる
本書の第1部は、ドメイン駆動設計の中核をなす考え方を説明している。複雑なソフトウェアに立ち向かうには、問題の本質を捉えた優れたドメインモデルが不可欠である。そのモデルを作り出すには、ドメインの知識を注意深く分析し、実装に適した形に洗練する「知識のかみ砕き」のプロセスが必要だ。
モデルはチーム全体で共有され、「ユビキタス言語」を通してソフトウェアに反映されなければならない。開発者は言葉の使い方に細心の注意を払い、コードがモデルを如実に表すようにする。モデルとコードの間に乖離があってはならない。
したがって、伝統的な「分析」と「設計」の分離をやめ、モデリングとコーディングを一体化した「モデル駆動設計」のアプローチを取るべきだ。そのためには、開発チームの全員が「実践的モデラ」となり、ドメインの理解とモデリングのスキルを持たねばならない。
ドメイン駆動設計は、難しいが大きな価値を生む。本書はそのためのノウハウを提供している。
第2部 モデル駆動設計の構成要素
本書の第2部では、ドメイン駆動設計を支える構成要素が詳述されている。
まず、ドメインを他の関心事から隔離することの重要性が説かれ、レイヤ化アーキテクチャによるドメイン層の分離が推奨される。ドメインの中核を成すのはエンティティと値オブジェクトであり、両者の違いを理解して適切に使い分けることが肝要だ。エンティティは同一性によって定義され、状態は変化するが同一性は不変。値オブジェクトは属性値によって定義され、不変で交換可能。
ドメインの操作は、エンティティや値オブジェクトに自然に属さない場合、サービスによってモデル化される。サービスは状態を持たない。
関連するオブジェクトの整合性を保つ必要がある場合、集約を定義する。集約はルートエンティティを中心に構成され、外部からはルートのみ参照可能とすることで不整合を防ぐ。
オブジェクトのライフサイクルを通じて、生成の複雑さを隠蔽するファクトリと、永続化を隠蔽するリポジトリが有用である。
関係データベースの制約にも配慮しつつ、パターンの適用とモデルの継続的な洗練によって、ドメインを忠実に表現する設計を追求することが重要である。
第3部 より深い洞察へ向かうリファクタリング
本書の第3部では、ドメインモデリングと設計をより深いレベルへと洗練させていくための考え方とテクニックが示されている。
鍵となるのは、ドメインへの継続的な学習と、モデルの表現力を高めるための地道なリファクタリングの積み重ねだ。その過程で、ときに飛躍的な前進（ブレイクスルー）が訪れる。こうした機会を活かすには、一時的な混乱を恐れず、チームが集中的に取り組む必要がある。
より良いモデルのためのヒントは、ドメインエキスパートとの対話や、既存のコードのぎこちなさ、ドメインの文献などから得られる。見出した概念は明示的にモデル化し、試行錯誤で洗練させていく。既存のアナリシスパターンやデザインパターンも、ドメインの文脈に合わせて応用できる。
こうして作り上げるモデルは、単に精緻なだけでなく、開発者にとって理解と拡張が容易な「しなやかさ」を備えていなければならない。意図が明快で、副作用がなく、概念の本質的な関連に基づく設計を目指す。
より深いモデルと、しなやかな設計は、ソフトウェアに対するチームの継続的な取り組みを通じて、少しずつ、ときに劇的に発展していく。それは直線的でも予測可能でもないプロセスだが、DDD実践者はその価値を信じ、チャンスを逃さずに前進し続ける。
第4部 戦略的設計
本書の第4部では、大規模で複雑なシステムを開発するためのドメイン駆動設計の戦略的な側面が論じられている。複数のチームによって開発が進められると、モデルの断片化が問題となる。そこで、「境界づけられたコンテキスト」の概念を用いて、モデルの適用範囲を明示的に定義し、「コンテキストマップ」によってシステム全体のコンテキストを整理する。コンテキスト間の関係は、共有カーネル、顧客/供給者、順応者など、状況に応じたパターンで統合される。
一方、「戦略的設計」では、モデルの本質的な部分である「コアドメイン」に注力し、汎用的な概念を括り出して純粋なコアを「隔離」「蒸留」する。開発者は、「凝集したメカニズム」を見出し、複雑な処理をまとめて隠蔽することで、ドメインモデルの本質を際立たせる。
大規模なシステムでは、「大規模な構造」によって、モデル全体に一貫性のある枠組みを与える。比喩的な「システムのメタファ」、階層的な「責務のレイヤ」、ランタイムの柔軟性を与える「知識レベル」、疎結合な「プラグイン可能なコンポーネントフレームワーク」など、様々なパターンが存在する。ただし、これらの構造は絶対的なものではなく、プロジェクトと共に「進化」させるべきだとされる。
複雑なシステムの核心を見極め、洗練していく過程では、開発チーム全体で「ユビキタス言語」を醸成し、境界づけられたコンテキストごとの「方言」を尊重しつつ、モデルについてのコミュニケーションを深めることが求められる。
各章の主要な概念
第1部 ドメインモデルを機能させる
第1章 知識をかみ砕く
開発チームがソフトウェアを役立つものにするには、対象ドメインの知識を身につける必要がある。しかし、情報は断片的で大量にあり、どれが必要かわからない。モデルはこの知識を選び抜いて意図的に構成したものであり、チームがモデルを作る過程で知識をかみ砕いていく。モデルが改良されるたびに、チームの理解が深まり、さらにモデルが洗練される。こうしたモデルは実用的で厳密でなくてはならない。
第2章 コミュニケーションと言語の使い方
モデルに基づいた言語（ユビキタス言語）を用いることで、チーム内のコミュニケーションが明確になり、実装とつながる。チームは言語を実験的に使用し、モデルを改良する。図やドキュメントも言語によって補完される。チーム全体がこの言語を使うことで相互理解が深まり、言語自体も進化する。
第3章 モデルと実装を結びつける
分析モデルと設計を分けるのではなく、単一のモデルを探し、モデルとコードを緊密に結びつける（モデル駆動設計）。モデルを忠実に実装し、フィードバックによってモデルを改良する。ユビキタス言語によってチーム全体の理解がモデルに反映される。モデリングとコーディングは分離せず、開発者全員がドメインを理解し、モデルに責任を持つ。
第2部 モデル駆動設計の構成要素
第4章 ドメインを隔離する
ドメインの概念を他の関心事から切り離すことで、モデルに集中できる。レイヤ化アーキテクチャでは、ドメイン層を分離。利口なUI アンチパターンは、ドメイン駆動設計と相容れない。レイヤ間の関係づけにはパターンがある。ドメインサービスは、ドメインの操作をモデル化。ドメイン層内でも差別化が必要。
第5章 ソフトウェアで表現されたモデル
関連の設計で無駄をなくす。エンティティは同一性で定義され、値オブジェクトは属性の値で定義される。サービスはドメインの操作を表現。モジュールはモデルを意味のある塊に分割。関係DBの制約に適応しつつ、モデルとの整合性を保つ。
第3部 より深い洞察へ向かうリファクタリング
第8章 ブレイクスルー
開発が進むと、突如として深い洞察が得られ、モデルと設計が大きく前進することがある。これをブレイクスルーと呼ぶ。ブレイクスルーは予測不可能だが、連続的なリファクタリングから生まれる。リスクもあるが、機会を逃してはならない。
第9章 暗黙的な概念を明示的にする
優れたモデルには、ドメインの中心となる概念が明示的に含まれる。開発者は、会話に出てくる手がかりや、設計のぎこちなさ、矛盾などから、そうした概念を見出さなければならない。見出した概念は試行錯誤でモデル化する。
第10章 しなやかな設計
意図が明確で、副作用のない関数や表明によって部品の組み合わせが安全になり、概念の輪郭に従った設計により意味の単位が安定する。こうしたしなやかな設計は、開発者が理解と変更を繰り返しながら、複雑さに立ち向かえるようにする。
第11章 アナリシスパターンを適用する
アナリシスパターンは、ドメインに関する他者の経験を利用できる。だが既製の解決策ではなく、洞察とモデリングの糧となる。プロジェクトの状況に合わせて選択し、現場の知識とかみ合わせる必要がある。
第4部 戦略的設計
第14章 モデルの整合性を維持する
複数のチームが関わる大規模プロジェクトでは、モデルの断片化が問題になる。これを防ぐため、モデルが適用される範囲を明示的に定義した「境界づけられたコンテキスト」の概念を導入する。さらに、コンテキストマップを描いてコンテキスト間の関係を整理し、関係性に応じた様々な統合方法を選択する。統合パターンには、共有カーネル、顧客/供給者開発チーム、順応者、腐敗防止層などがある。
理解度チェック用の質問文
第1部 ドメインモデルを機能させる
第1章
- 知識をかみ砕くとはどういうことか？
- モデルの目的は何か？
- チームの理解とモデルの関係はどのようなものか？
第2章
- ユビキタス言語とは何か？
- チームはどのようにしてモデルを改良するか？
- 言語はどのようにしてチームのコミュニケーションを明確にするか？
第3章
- モデル駆動設計とは何か？
- 分析モデルと設計を分けることの問題点は何か？
- 開発者がモデリングから離れてはいけない理由は何か？
第2部 モデル駆動設計の構成要素
第5章
- エンティティと値オブジェクトはどのように区別されるか？
- サービスはドメインモデルにおいてどのような位置づけか？
- モジュール分割の目的は何か？
第6章
- 集約はどのような問題を解決するか？
- ファクトリの役割は何か？
- リポジトリはオブジェクトのライフサイクルのどの段階を扱うか？
第3部 より深い洞察へ向かうリファクタリング
第8章
- ブレイクスルーとは何か？どのようにして起こるか？
- ブレイクスルーにはどのようなリスクがあるか？
- ブレイクスルーが起きた時にチームはどう行動すべきか？
第9章
- ドメインの中心的な概念を見出すために、開発者はどこに着目すべきか？
- 見出した概念をどのようにモデル化すればよいか？
- 仕様オブジェクトとは何か？どのような利点があるか？
第10章
- しなやかな設計とはどのようなものか？なぜ必要か？
- 意図が明確な設計とは？どう実現できるか？
- 概念の輪郭とは何か？設計はそれにどう従うべきか？
第13章
- より深い洞察へ向かうリファクタリングで重要な3つのポイントは？
- より深い洞察へのブレイクスルーはどのようなきっかけで起こるか？
- ブレイクスルーの機会をどう捉えるべきか？
第4部 戦略的設計
第14章
- 境界づけられたコンテキストとは何か?なぜそれが重要なのか?
- コンテキストマップにはどのような要素が含まれるか?
- 境界づけられたコンテキストを統合する代表的なパターンにはどのようなものがあるか?
第15章
第16章
- 大規模な構造を導入する目的は何か?代表的なパターンにはどのようなものがあるか?
- 知識レベルとはどのような概念か?それによってどのような利点が得られるか?
- 「進化する秩序」とはどういう意味か?なぜ大規模な構造は「進化」すべきなのか?
重要な概念の解説
第1部 ドメインモデルを機能させる
第2部 モデル駆動設計の構成要素
- レイヤ化アーキテクチャ：アプリケーションを複数の層に分割する設計手法。ユーザインタフェース層、アプリケーション層、ドメイン層、インフラストラクチャ層に分ける。ドメイン層を他の関心事から隔離できる。
- エンティティ：同一性によって定義されるオブジェクト。エンティティの状態は変化するが、同一性は不変。
- 値オブジェクト：属性の値によって定義されるオブジェクト。不変であり、交換可能。
- サービス：ドメインの操作を表現するが状態は保持しないオブジェクト。エンティティや値オブジェクトに自然に属さない操作を受け持つ。
- 集約：整合性を保つ必要のある関連オブジェクトの集まり。ルートエンティティを中心に構成され、境界の外部からはルートのみ参照可能。
- ファクトリ：オブジェクトの生成の複雑さを隠蔽し、生成ロジックを集約するオブジェクト。
- リポジトリ：永続化の複雑さを隠蔽し、オブジェクトのライフサイクルを管理するオブジェクト。
第3部 より深い洞察へ向かうリファクタリング
- ブレイクスルー： 開発者がドメインへの深い理解を得て、モデルや設計が飛躍的に改善されること。予測は難しいが、継続的なリファクタリングから生まれる。リスクもあるが、大きなチャンスでもある。
- 暗黙的な概念： ドメインの重要な概念のうち、まだモデルで明示的に表現されていないもの。会話の端々に表れたり、既存の設計のぎこちなさの原因になっていたりする。見出して明示的にモデル化することが重要。
- しなやかな設計： 意図が明確で、副作用がなく、概念の輪郭に合致した設計。開発者が理解と拡張を繰り返しやすくなる。深いモデリングと相互に補完し合う。
- アナリシスパターン： ドメインに関するベストプラクティスをパターン化したもの。モデリングのヒントを与えてくれるが、そのまま当てはめられるわけではない。プロジェクトの文脈に合わせて応用する。
- 概念の輪郭： ドメインの中で本質的に関連し合う概念の集まりの境界線。モデルと設計は、この輪郭に沿って構成要素を切り出すべきである。
第4部 戦略的設計
- 境界づけられたコンテキスト: モデルを適用できる範囲を明示的に定義したもの。モデルの断片化を防ぎ、言語的な統一性を保つ。
- コンテキストマップ: システムを構成する複数のコンテキストとその関係を俯瞰的に示した地図。統合作業の指針となる。
- 戦略的設計: モデルの本質を見極め、洗練させるための継続的な取り組み。コアドメインを際立たせ、モデルを深化させる。
- コアドメイン: システムの中で最も価値を生み出す、特徴的なモデルの部分。戦略的設計の主眼となる。
- 汎用サブドメイン: ドメインに関連するが、標準的な概念を扱う、再利用可能なモデルの部分。コアドメインの対比として重要。
- 大規模な構造: システム全体を貫く設計上の方針や概念的な枠組み。モデルに一貫性をもたらし、開発者間のコミュニケーションを助ける。
- 凝集したメカニズム: 複雑だが、まとまりのある一連の処理を隠蔽するサブシステム。ドメインモデルのもつれを解消する。
- ユビキタス言語: チーム全体で共有されるモデルについての言語。境界づけられたコンテキストごとに「方言」が存在する。
- パターン: 文脈を共有する問題に対する、再利用可能な解決の枠組み。パターンは名前、問題、解決、結果で構成される。
考察
第1部 ドメインモデルを機能させる
エリック・エヴァンスの「ドメイン駆動設計」は、複雑なソフトウェア開発に挑むための強力な方法論を提示している。その中核をなすのは、問題領域を深く理解し、その本質を巧みにモデル化することだ。開発チームがドメインの専門家と協力し、徹底的に知識をかみ砕いてソフトウェアの設計に落とし込む。コードはモデルを如実に反映し、ドメインの言葉がそのまま生きる。
これは理想的なアプローチだが、実践には高いハードルがある。専門的知識を持つ担当者の確保、チーム全体でのスキル習得、綿密なコミュニケーションなど、なかなか難しい課題が多い。また、モデリングとコーディングの一体化は、技術的複雑性を増す恐れもある。
とはいえ、著者の豊富な経験に基づく指針は示唆に富む。単に形式的な方法論ではなく、プロジェクトを成功に導く哲学と言える。ポイントは、ドメインの専門性とソフトウェア構築のスキルを統合することにある。チームワークと学習を重視する組織文化も欠かせない。
従来の開発方式への根本的な挑戦であるだけに、一朝一夕には浸透しないだろう。だが、イノベーティブなシステムを生み出すには欠かせないアプローチと言える。人材育成を含め、息の長い取り組みが求められる。本書で提示された知見は、これからのソフトウェア開発を導く指針となるはずだ。
第2部 モデル駆動設計の構成要素
本書の第2部は、ドメイン駆動設計の中核をなす構成要素を体系的に提示しており、モデルを実装に落とし込む上で道標となる。レイヤ化による関心事の分離、エンティティと値オブジェクトの使い分け、サービスによる操作のモデル化など、示されたパターンは納得感があり、実践的である。
特に、モデルの実装において陥りがちな、トランザクション整合性の問題に対する集約の導入は腑に落ちる。また、ライフサイクル管理の複雑さを隠蔽するファクトリやリポジトリは、モデルに集中するためにも不可欠だ。終盤の貨物輸送ドメインの例は各要素の適用イメージを掴むのに役立つ。
一方で、関係データベースとの整合性をいかに保つかについては、やや深掘りが足りない印象を受けた。モデルとテーブル設計の乖離は実務ではよく直面する問題であり、両者のバランスについてはもう少し議論が欲しかった。
とはいえ、ドメインモデルをどう実装に落とし込むかという普遍的な課題に対し、筋の通った方法論を提示した点で、本書の価値は非常に高い。経験則に基づくパターンの適用と、フレームワークとの整合性の取り方など、示唆に富む知見が随所に見られた。エンティティや集約など、用語の定義も明快で、ドメインモデリングを行う上で常に参照したくなる良書である。
全体としては、ソフトウェア開発の本質であるモデリングと実装の間の翻訳を、いかにして整合性高く行うかを真摯に考究した良著であり、難解なドメインに立ち向かう開発者必読の書と言えるだろう。
第3部 より深い洞察へ向かうリファクタリング
「エリック・エヴァンスのドメイン駆動設計」の第3部は、洗練されたドメインモデリングと設計のための実践的な指針を提示している。それは、単に技法の羅列ではない。むしろ、開発者に、ドメインを深く理解し、その本質を細部に至るまでソフトウェアに反映させようとする姿勢を求めている。
特に印象的なのは、「ブレイクスルー」というアイデアだ。画期的な発見や大幅な改善は、スケジュール通りに起きるわけではない。だが著者は、日々の地道な歩みを信じ、チャンスを逃さない用意を促している。これは、ソフトウェア開発というクリエイティブな営みの本質を捉えた洞察だと言えるだろう。
また、「しなやかな設計」の重要性も説得力を持って語られている。ドメインを深く理解しても、それを使いやすいコードに落とし込めなければ意味がない。かといって、設計のための設計に走ってもいけない。あくまで、ドメインの概念を明晰に、安全に、過不足なく表現できることが肝要なのだ。
反復的に理解を深め、モデルを練り上げ、設計をしなやかに進化させること。著者が説くこのプロセスは、きれいごとを言っているわけではない。変化を恐れず、試行錯誤を厭わない覚悟が必要だ。トレードオフも避けられない。だがそれでも、ドメインモデリングを真摯に追求する意義は失われないと、私は本書から教えられた。
もちろん、すべてのプロジェクトでここまで突き詰められるわけではないだろう。モデルの妥当性の評価も難しい問題だ。とはいえ、現実と向き合いながら、ソフトウェアにドメインの本質を宿すことをあきらめない姿勢には、大きな感銘を受ける。設計のプロとして、この高い理想に少しでも近づきたいと思わずにはいられない。
第4部 戦略的設計
本書の第4部で提示されている戦略的設計の原則とパターンは、大規模で複雑なシステムを開発する上で、極めて示唆に富む指針となっている。特に、モデルの断片化を防ぐための「境界づけられたコンテキスト」、本質を見極めるための「戦略的設計」、全体を見渡すための「大規模な構造」は、ドメイン駆動設計の真髄といえる考え方であり、複雑なドメインに立ち向かう開発チームにとって、羅針盤のような役割を果たすものといえる。
著者のエリック・エヴァンスは、実際のプロジェクトで得られた知見をもとに、抽象的な原則だけでなく、具体的で実践的なパターンを数多く提示している。「コンテキストマップ」「責務のレイヤ」「プラグイン可能なコンポーネントフレームワーク」など、エンジニアリングの現場ですぐにでも活用可能なテクニックが詰まっていることは、本書の大きな魅力の1つである。
また、「進化する秩序」という考え方は、アジャイル開発の思想とも通底するものがあり、ソフトウェア開発プロセス全般に対する重要な示唆を与えている。drilldownとemergenceのバランスを重視し、状況の変化に柔軟に対応しながら、モデルを洗練していく姿勢は、DDD実践者のみならず、全てのソフトウエアエンジニアが学ぶべき教訓だと言える。
一方で、「凝集したメカニズム」や「知識レベル」といった概念は、やや抽象度が高く、実践の難易度も高いと感じられた。これらのパターンをどのように実装に落とし込むか、具体的な事例を交えた補足説明があればより理解が深まったのではないだろうか。
また、ドメインモデリングとユビキタス言語の重要性は本書全体を通して強調されているが、複数の「方言」が生まれた場合の言語的な統合プロセスについては、もう少し踏み込んだ議論が欲しいところである。
とはいえ、これらはあくまで些細な望蜀の念に過ぎない。エリック・エヴァンスが提唱する戦略的設計の原則とパターンは、今日のソフトウエア開発に携わる技術者に対し、示唆と活力を与えてくれる貴重な知的資産である。系統的で論理的な議論の末に、「優れたソフトウエアを作成することは、学び考える活動である」という含蓄のある言葉で結ばれていることからも、著者の豊かな洞察が窺い知れる。本書は、単なる開発技法の解説書ではなく、ソフトウエアエンジニアリングの真髄を問う、1つの思想書としても読み継がれるべき書物だと言えるだろう。
まとめ
エリック・エヴァンスの「ドメイン駆動設計」は、複雑なソフトウェア開発に立ち向かうための強力な方法論を提示している。その中核をなすのは、問題領域を深く理解し、その本質を巧みにモデル化し、ソフトウェアに反映させることだ。開発チームがドメインの専門家と協力し、知識をかみ砕いてモデルを構築する。そのモデルは、ユビキタス言語を通してチーム全体で共有され、コードに直接的に反映される。
本書で解説されている、レイヤ化アーキテクチャ、エンティティと値オブジェクト、集約、ファクトリ、リポジトリなどの構成要素は、モデルを実装に落とし込む上で強力な手がかりとなる。一方、関係データーベースとの整合性の取り方など、実践上の難しさも残されている。
より洗練されたモデルを目指すには、ブレイクスルーのチャンスを逃さず、しなやかな設計を追求する必要がある。そのためには、アナリシスパターンやデザインパターンを応用しつつ、試行錯誤を重ねる覚悟が問われる。
さらに、複数のチームが関わる大規模なシステム開発では、戦略的設計の原則とパターンが不可欠だ。境界づけられたコンテキスト、コンテキストマップ、コアドメインの見極めなどにより、モデルの断片化を防ぎ、本質を追求することができる。状況の変化に合わせてモデルを進化させる柔軟な姿勢も重要となる。
ドメイン駆動設計は、理想的ではあるが実践のハードルも高い。組織の文化や個人のスキルの問題も絡む。とはいえ、ソフトウェア開発の真髄を捉えたアプローチであることは間違いない。イノベーティブなシステムを生み出し、ビジネス価値を高めるには、避けて通れない道のりなのだ。本書から学んだ洞察を糧に、地道な努力を重ねていきたい。
