タイトル (ページ) †
Preface (xix)
要約 †
- 導入
- ソフトウェア設計を牽引する人々は、少なくともこの２０年はドメインモデリングとドメインデザイン*1が重要なトピックであると認識してきた。それが明確に定式化されることはなかったが、オブジェクト指向コミュニティにおいては、私が「ドメイン駆動デザイン（domain-driven design）」と呼ぶ哲学が、底流としてあらわれてきた。
- 自分の経験上でも、成功したプロジェクトにはしっかりとしたドメインモデルが設計を通じて形成され、プロジェクトの骨組みを形成していた。
この本は設計上の意思決定をする上で必要となる枠組みと、ドメインデザインについて議論をするうえでの技術的な語彙を提供するものである。この枠組みはドメイン駆動デザインにたいして体系的にアプローチするために有効であろう。
- ３つのプロジェクトの対比
- ドメインデザインを実践することがプロジェクトの結果にどう影響するかを示すために、具体例を挙げる。
- ドメインモデル不在の失敗パターン
役に立つが単純なWeb取引システム。単純であったため、デザインは重要視されなかった。初回のリリースは成功したが、結局、バージョン２をリリースすることはできず、バージョン１はレガシーと化した。
- 成功例
成功の原因は、明快なドメインモデルが継続的にブラッシュアップされ、コード内でも表現されていたこと。
- モデルと実装が乖離した失敗パターン
ドメインモデルを重要視はしていたが、開発者の役割分担に問題があり、実装からモデルが切り離されてしまった。イテレーションのたびにコードは劣化し、数ヶ月もするとシステム全体を見通すことができなくなった。ある程度は使えるソフトウェアはリリースできたものの、当初の目標は達成できなかった。
- 複雑さに対する挑戦
- プロジェクトを破綻させる要因は多いが、ソフトウェアがどの程度複雑になるかを左右するのはデザインに対するアプローチである。
- デザインのいくつかの要素は技術的なものであり、その点については多くの成果があがっている。
- しかし、多くのアプリケーションにおいて最も重要な複雑さは、技術的なものではなく、ドメインそれ自体、つまり、ユーザーの活動や業務なのだ。デザインを成功させるためには、このソフトウェアの中核を体系的に扱わなければならない。
- この本の前提は以下の二点からなる。
- ほとんどのソフトウェアプロジェクトは、第一にドメインとドメインロジックに焦点を当てるべきである。
- 複雑なドメインデザインはモデルを基礎とするべきである。
- 複雑なドメインを扱わなければいけないソフトウェアプロジェクトを推進するというドメイン駆動デザインの目的を達成するために、この本では広範囲にわたるデザインの実践、テクニック、そして、原則を紹介する。
- デザインと開発プロセス
- デザインを扱う書物と開発プロセスを扱う書物は、あまり相関関係を持っていなかった。しかし、筆者はデザインと開発プロセスは密接に結びついていると考える。
- 開発者は確かにデザインの原則をどう適合させるかという抽象的な議論をすることもあるが、実際には現実の問題をどう解決するかを話し合うものだ。だからこの本では必要に応じてプロセスについても語ることにする。
- この本は特定の方法論にしばられるものではないが、新しい「アジャイル開発手法」の系譜にあわせたものであり、特に、以下の二点は前提とされている。
- 「イテレーション」開発
- 開発者とドメイン専門家の間の緊密な関係
- なお、ＸＰは最も普及したアジャイル開発プロセスであり、筆者自身が多く経験しているものであることから、デザインとプロセスとの関連について議論をする際には、ＸＰを利用する。
- ここ数年、アップフロント型の開発手法に対する反発として、ＸＰのように変化に対応していくことを強調するアジャイル手法があらわれてきた。
- ＸＰは設計上の決定を重要視しつつも、アップフロントの設計に反発する。コミュニケーションを重視することで、変化に対して、俊敏に対応する。「必要最小限のシンプルなもの」を用い、継続的にリファクタリングを行い、最終的に顧客の要求に見合うデザインに至る。
- このミニマリズムは「分析麻痺（analysis paralysis）」に対する解毒剤となってきた。
- しかし、残念ながらこういった開発プロセスの考え方は誤解を招きうる。
- 「シンプル」の概念は人によって異なる。
- 拙い開発者が産み出すリファクタリング不可能なコード。
- 「シンプル」であろうとして深く設計できなくなる。
- ＸＰは鋭い設計センスを持つ開発者において機能するものだ。
- ＸＰはリファクタリングによりデザインを改善できると想定するが、リファクタリングの成否はそれまでの設計に依存する。
- ＸＰはチーム内のコミュニケーションを促進しようとするが、モデルと設計はコミュニケーションを妨げることもある。
- 本書はデザインと開発の実践を絡み合わせ、ドメイン駆動デザインとアジャイル開発がどのように互いを強化するのかを説明するものだ。アジャイル開発プロセスの文脈において、ドメインモデルに対し洗練されたアプローチをとることで開発が促進される。ドメイン開発とプロセスとの相互関係を扱うことではじめて、このアプローチは、抽象的な設計を扱うだけではなし得ない、実践的なものとなるのである。
- 本書の構造
- 第一部：ドメインモデルを機能させる
ドメイン駆動開発における基本的な目的を示す。用語を定義し、コミュニケーションとデザインを推進させるためにドメインを利用するということがどういうことであるのかを示すための概略を提示する。
- 第二部：モデル駆動デザインの構成要素
オブジェクト指向ドメインモデリングにおいて中核となるベストプラクティスを、基本的な構成要素に凝縮させる。ここでは、モデルと実際に稼動するソフトウェアとの間の橋渡しを行なうことに焦点をあてる。
- 第三部：より深い洞察のためのリファクタリング
構成要素を超えて、実践的なモデルへと集約させるための挑戦へ。単にデザインの原則を提示するのではなく、「発見」のプロセスを重視する。
- 第四部：戦略的デザイン
ここでは、複雑なシステム、より大規模な組織、外部システムや、レガシーとの関連といった局面において現れる状況について扱う。
- 対象読者
- まず第一に、オブジェクト指向ソフトウェアの開発者。実際にプロジェクトに参画して開発を行なっている人々にとって、役に立つ部分があるだろう。
- ある程度のオブジェクト指向の知識は必要である。具体例にはUMLやJavaコードが含まれているので、これらの言語をある程度読めることは必要だが、詳細まで習得している必要は無い。また、ＸＰについての知識があると、開発プロセスの議論について見通しが立つが、知らなければ理解できないというものではない。
- 中級のソフトウェア開発者、つまり、オブジェクト指向デザインについてある程度の知識があり、ソフトウェアデザインの書籍を一冊二冊読んでいるような人々にとっては、理論と実践との橋渡しを。
- 上級、または職人クラスのソフトウェア開発者は、本書がドメインモデルを扱う「包括的な枠組み（comprehensive framework）」に興味を持つだろう。
- 開発に直接携わる読者以外にも、アナリストや、やや技術指向のプロジェクトマネージャーにとっても得るものがある。アナリストにとっては、モデルとデザインとの関連が役に立つし、戦略的デザインの原則もいくつか利用できるだろう。
- プロジェクトマネージャーは、チームをより効率的にする点に、そして業務の専門家とユーザーにとって意味のある形でソフトウェアをデザインすることに焦点をあてた点に興味を持つだろう。
- ドメイン駆動チーム
- ドメイン駆動デザインが真価を発揮するのは、チーム全体で協力し合ってドメイン駆動アプローチを取り入れ、ドメインモデルをプロジェクト内で話し合われることの中心にすえた時である。
- ドメイン駆動デザインは困難ではあるが、プロジェクト内で成熟してゆけば、大きな収穫をもたらすことができるだろう。
担当者のつぶやき †
アジャイル手法は、先進的な会社と読書好きな人々の間ではもはや常識になりつつある反面、相変わらずの「ウォーターフォール」形式と手続き的実装を行っている所もまだまだ多いのが実情ではないかと思います。その場合、DDDを「ドメインモデルパターン集」的な位置にすえると、「ホントはやりたいんだけど、うちでは無理だね〜」的な結論に至らざるを得ないと思うのですが、おそらくそれはもったいない気がします。
DDDでは、ドメインモデルについて考える際の「枠組み」を提示することに重点が置かれており、また、開発という局面で「話し合いながら理解を深めていくこと」が非常に重視されています。現実問題として、最終的にどこかでドメインモデルとパラレルな形で実装することを諦めなければいけないとしても、努力を一切しなくてよいわけではないですから、そういう意味でエバンスの「考え方」を学び取るのは十分に価値があると思います。
その上で、「ドメインモデル」をどう生かし、どう現実と折り合いをつけていくのかが重要で、その点にいつも頭を悩ませています。今回の勉強会では、実際に参加されている方々がどう戦略をたて、どう成功しあるいは失敗してきたのかについて、色々議論したいと考えています。
みんなの突っ込み †
- デザインと開発プロセス：本書の前提とされている「開発者とドメイン専門者がコラボッた数10年間のイテレーション」というのは現実的に可能なんでしょうか・・・ -- 池田?
- ものの本では「イテレーション開発はもう当然」みたいな感じですが、実際の業務開発の現場ではトンと見かけたことがないですね・・・。理想として、外部設計くらいまでを、SEと業務プロとでがっちりしたものを作り上げることができたらいいとは思っているのですが。余談ですが、"for decades"って普通に読めば「数十年」って含みだと思うのですが、「イテレーション開発」が提唱されてからまだそこまで経ってないですよね？これはちょっと大げさに表現したジョークなのか、それとも、実際"decade"のニュアンスは薄れていて「ここしばらく」みたいな語感で使えるのか・・・どなたかご存知な方、いらっしゃったら教えて下さい。["Iterative development has been advocated and practiced for decades,..."(p.xxii)] -- 和智?
