導入(xii)

ドメインモデリングと設計について、オブジェクトコミュニティである哲学が生まれていた。
エリックエヴァンスは、その哲学を「ドメイン駆動設計」と呼んでいた。
10年間、様々なシステム開発に携わってきたエヴァンスだったが、その中には成功したものもあれば、失敗したものもあった。
成功したプロジェクトに共通していたのは、豊かなドメインモデルだった。
ドメインモデルは、プロジェクトの進行とともに進化し、プロジェクトの基礎の１つとなっていた。
DDD 本では、ドメイン駆動設計を体系的に実践するためのフレームワークを提供する。

対照的な３つのプロジェクト (xii)

３つのプロジェクトの比較。
どのプロジェクトも、役立つソフトウェアは完成した。
しかし、野心的な目標を達成し、企業の継続的な要求を満たすべく進化し続けるソフトウェアを作成できたのは１つだけだった。
１つ目のプロジェクト（ダメな例）
- シンプルで便利な Web システムを素早く作成できた。
- しかし、第２バージョンのリリースは１年かかってもできずにいた。
- このプロジェクトには様々な問題があった。
  - ドメインモデルが存在しなかった。
  - 共通言語がなかった。
  - 構造化された設計がなかった。
２つ目のプロジェクト（良い例）
- このプロジェクトはドメイン設計を重視していた。
- 初回リリースは成功し、その後も継続的に開発が加速した。
- ドメインモデルはイテレーションのたびに改良されていった。
- 開発者間だけでなく、開発者とドメインエキスパート間のコミュニケーションも向上していった。
- 設計のせいで保守がしづらくなることもなく、むしろ容易に変更することができた。
３つ目のプロジェクト（ダメな例）
- このプロジェクトもドメインモデルを重視しようという高尚な意志があった。
- チームはモデリングを慎重に進めていった。
- しかし、開発者の役割を誤って分割していたため、モデリングと実装が切り離された。
- 深い分析は、設計に反映されなかった。
- ビジネスオブジェクトの設計は、実際に実装できるほど厳密ではなかった。
- 数か月後、開発は複雑さの泥沼にはまっていた。
- それ相応に役立つソフトウェアはできたが、ドメインモデルは捨てられ、初期の大志は失われていた。

まとめ

ドメインモデルを重視しなくても、役立つシステムをリリースすることはできる。
しかし、その後も継続してビジネスの変更に対応できるようにするには、豊かなドメインモデルとその改良が必要になる。
ただし、ドメインモデルを重視しているだけでは成功しない。モデリングと実装を結び付ける方法が必要になる。

複雑さという課題 (xiv)

ソフトウェアが複雑になれるかどうかを決めるのは、設計に対するアプローチが主要因。
複雑さが手に負えなくなってしまうと、
- 開発者はソフトウェアを理解できなくなる
- 変更や拡張を安全かつ容易に行えなくなる
優れた設計なら、逆にその複雑な特徴を活用する機会を作り出せる。
ソフトウェアで最も重要な複雑さは、ドメインそのものが持つ複雑さ。
- すなわち、ユーザーの活動やビジネスそのもの。
ドメインの複雑さが設計で考慮されていなければ、どんな技術を使っていようが意味がない。
設計を成功させるには、このドメインの複雑さを体系的に扱わなければいけない。
ドメイン駆動設計が前提とすること。
1. ソフトウェアプロジェクトの一番の焦点は、ドメインとドメインロジック。
2. 複雑なドメインの設計は、モデルに基づかなければならない。
ドメイン駆動設計の目標。
- 複雑なドメインを扱うソフトウェアプロジェクトを促進させること。
DDD 本では、この目標を達成するためのプラクティスおよび原則を紹介している。

まとめ

ソフトウェアが複雑になりすぎると、開発者もソフトウェアを理解できなくなり、修正もしづらくなる。
ソフトウェアの複雑さの核心は、そのソフトウェアが対象とするドメインそのものの複雑さで、これを設計で扱わなければ意味がない。
ドメイン駆動設計は、この複雑なドメインを扱わなければならないソフトウェアの開発を、いかにして進めて行けばいいか、その手法を紹介している。

設計対開発プロセス (xv)

設計とプロセスは切り離すことができない。
設計は実装に落とし込めなければ意味がない。
DDD 本は設計について扱う本だが、必要に応じてプロセスについても言及する。
ドメイン駆動設計を適用するうえで、２つのプラクティスが定着していることが前提条件となっている。
1. 開発がイテレーティブである
  - アジャイル開発、 XP など。
2. 開発者とドメインエキスパートが密接に関わっている
  - DDD は、ドメインを理解している人とソフトウェアの構築方法を知っている人で行う共同作業。
DDD 本では、説明の基礎として XP (エクストリームプログラミング)を使用している。
しかし、 XP 以外のアジャイルプロセスでも適合させることはできる。
アジャイル（および XP）についての説明。
- アジャイルプロセスは、変化と不確実さに対処する能力を重視する。
- XP では「コミュニケーション」と「プロジェクトの対応能力の改善」に重点を置いている。
- 変化への対応能力を身に着け、設計を継続的に改善することで、顧客の真の要求にたどり着く。
- アジャイルプロセスは、「設計が完全でないと考えるあまり仕事が進まなくなる人たち」に対応するための手段として生まれた。
- しかし、確固たる設計原則がない状態でリファクタリングや再設計を繰り返すと、コードは理解不能なものになり、俊敏さ（アジャイル）とはかけ離れたものになる。
- XP を実践するには設計のセンスが必要。
- モデルや設計の選択次第では、その後のコミュニケーションが明確になることもあれば、混乱することもある。
DDD 本は、ドメイン駆動設計とアジャイル開発がどのように補強し合うかを説明する。
アジャイル開発（プロセス）でドメインモデリング（設計）が行われれば、開発は加速する。
このため DDD 本が説明するドメイン駆動設計は、設計だけを扱っている他のアプローチに比べて、より実用的になっている。

まとめ

どんなに設計の考え方が良くても、実装に落とし込めなければ意味がない。
そのため、 DDD 本は設計の本ではあるが、必要に応じてプロセスについても言及しており、設計だけを扱っている他のアプローチよりも、より実用的になっている。
具体的には、ドメイン駆動設計はアジャイル開発プロセスを意識しており、「開発がイテレーティブであること」と「開発者とドメインエキスパートが密接に関わっていること」はドメイン駆動設計の前提となっている。

本書の構成 (xvii)

第１部：ドメインモデルを機能させる
- ドメイン駆動設計の基本的な目標を紹介。
- ここで紹介する目標が、第２部以降で紹介するプラクティスを実践する動機となる。
- また、 DDD 本で使用されている用語の定義を説明する。
- ドメインモデルがコミュニケーションと設計を推進する、とはどういうことが概要を説明する。
第２部：モデル駆動設計の構成要素
- ここで重点を置くのは、「モデルと実装の間にある溝を埋めること」
- 第２部で一番重要なことは、「モデルと実装を互いに結び付け、片方がもう一方を補強するような意思決定に集中すること」
- 第２部では、そのために必要となるオブジェクト指向ドメインモデリングの基本的な構成要素を説明する。
- 共通言語を用いれば、チームメンバ全員がモデルと設計上の意思決定について議論できるようになる。
- モデルと実装との整合性を維持するには、個々の構成要素の詳細に注意する必要がある。
- 個々の構成要素を丁寧に作り上げれば、第３部以降で紹介するモデリングアプローチを実践するための安定した土台を手に入れることができる。
第３部：より深い洞察へ向かうリファクタリング
- 第３部では、個々の構成要素を超えて利益をもたらす、実用的なモデルをどのように組み立てるのかについて説明する。
- ここでは、すぐに結論を出すのではなく、なぜそのような結論に至ったか、そのプロセスを重視する。
- 価値のあるモデルはすぐには姿を現さず、ドメインに関する深い理解が必要となる。
- ドメインについての洞察を得るたびに、モデルを改良し、コードにその変更を反映する。これを繰り返さなければならない。
- この地道な作業が、さらに深いモデルへとブレイクスルーする機会につながる。
- 第３部で掘り下げる内容
  1. ドメインの探求の途中で選択の指針となるモデリングの原則
  2. 探求を方向付けるのに役立つテクニック
第４部：戦略的設計
- 以下のような状況に対処する方法を説明する。
  1. 複雑なシステムや大企業
  2. 外部システム・レガシーシステムとの相互作用
- ここで検討するのは３つ組の原理
  1. コンテキスト
  2. 蒸留
  3. 大規模な構造
- 第１部で示したドメイン駆動設計の目標が、より大きな規模で実現できるようになる。

まとめ

第１部で、ドメイン駆動設計の用語の定義や目標の確認などを行う。
第２部は、モデル駆動設計を実現するために必要となる個々の構成要素を紹介する。ここで紹介された個々の構成要素は、その後のモデリングパターンを実践するうえで安定した土台になる。
第３部では、ドメインについての洞察をさらにモデルやコードに反映させていく方法を説明する。
第４部では、大規模なシステムを扱う場合に遭遇する問題にどう対処すべきかを説明する。

本書が対象とする読者 (xviii)

DDD 本は、オブジェクト指向ソフトウェアの開発者向けに書かれている。
以下については、基礎は知っているべきだが、詳細まで知っている必要はない。
- オブジェクト指向モデリング
- UML
- Java
XP については知っておいたほうがいいが、知らなくても内容を理解することはできるはず。
既にオブジェクト指向設計について学習している中級者は、オブジェクトモデリングを実際のソフトウェア開発にどのように当てはめればいいかを学び、理論と実践の隙間を埋めるのに役立つ。
上級のソフトウェア開発者は、ドメインを扱うための包括的なフレームワークに関心を持つだろう。
- そして、設計に関する体系的なアプローチによって、自身のチームを導くことができるようになる。
DDD 本は物語風になっている。
どこから読んでもよいが、エヴァンス自身は第１部の導入と第１章から読むことを推奨している。
ある程度テーマを理解している人は、各章の冒頭と太字の部分だけを読めば、要点を拾い上げられるようになっている。
アナリストやプロジェクトマネージャー（PM）も得るものがあるだろう。
- アナリスト
  - モデルと設計とのつながりを活用することで、アジャイルプロジェクトでさらに貢献できる。
  - 戦略的設計の原則を使うことで、これまで以上に自分たちの仕事に集中して、それをまとめ上げることができるかもしれない。
- PM
  - 本書が強調していることは、「チームを、ユーザにとって意味のあるソフトウェア設計に集中させること」。
  - PM は間違いなくこの点に興味を持つだろう。
  - また、戦略的設計における意思決定は、チーム編成や作業スタイルと関係するので、必然的にPMの仕事に関係してくる。

まとめ

DDD 本はオブジェクト指向ソフトウェアの開発者向けに書かれており、それらに関する知識が多少必要になる。
中級者にはオブジェクト指向の実践方法として有用であり、上級者にはドメインを捉える方法やリーダーとしてチームを導くのに有用な情報を含んでいる。
また、アナリストやPMにとっても興味を持てる内容が含まれている。
DDD 本はどこから読んでも構わないが、おすすめは第１部の導入・第１章から読むこと。要点を掻い摘んで読むこともできるようになっている。

ドメイン駆動チーム (xix)

DDD を通じて、個々の開発者が得られるものもある。
しかし、最大の収穫が得られるのは、チームが一致団結して DDD を実践し、ドメインモデルを会話の中心に据えたとき。
チームはドメインモデルを通じて言葉を共有し、コミュニケーションが豊かになる。
チームはモデルと一致した明快な実装を作り出し、アプリケーション開発に力を与える。
また、複数のチームが関わるとき互いの関係を示す地図¹を共有することで、組織が必要とする機能を実現する際に体系的に開発に取り組むことができるようになる。
ドメイン駆動設計は技術的な困難を伴う。しかし、これを達成すればソフトウェアがレガシーへと風化するのを止め、逆に大きく進化するチャンスへとつなげることができる。

コンテキストマップ？ ↩

DDD 読書メモ まえがき