単語
- ドメイン
- 業務領域のこと
- ドメイン駆動設計
- 哲学
- 業務領域に合わせて適切な知識をもって設計を行うこと
- ドメインエキスパート
- 開発しているソフトウェアの適用領域（ドメイン）に深く通じている人
- エクストリームプログラミング(XP)
- アジャイル開発における開発手法の１つ
- 最初に綿密な計画を立てず、臨機応変に進める開発方法のこと。
- 設計・実装・テストを短期間で何度も繰り返しながら、顧客の意見や要望を都度取り入れて開発を進めます。
本書の前提
- ほとんどのソフトウェアプロジェクトにおいて、一番の焦点は、ドメインとドメインロジックに合わせなければならない。
- 複雑なドメイン設計は、モデルに基づかなければならない。 ドメイン駆動設計は、1つの考え方であると同時に、ひとまとまりの優先順位でもあり、入り組んだドメインを扱わなければならないソフトウェアプロジェクトを促進することを目指している。 本書では、設計のプラクティスやテクニック及び原則を幅広く紹介する。
本書のアプローチを行う上での前提条件
- 開発がイテレーディブである
- アジャイルを採用していればOK
- 開発者とドメインエキスパートが密接に関わっている
- ドメイン駆動設計は、膨大な知識を噛み砕き、ドメインについての深い洞察と、集中すべき主要な概念を反映したモデルをこうちくするためである。
- ドメインを理解している人と、ソフトウェアの構築方法を知っている人で行う共同作業である。
- 開発がイテレーティブであるため、この共同作業はプロジェクト期間中、ずっと継続しなければならない。
- 本書では議論の基礎としてXPを使用する。
- XP以外のアジャイルプロセスにも容易に適合させることができる。
- 設計(XP)と開発のプラクティスを絡み合わせ、ドメイン駆動設計とアジャイル開発が、どのように相互に補強し合うか説明する。
- ドメインモデリングに対する洗練されたアプローチが、アジャイル開発プロセスにおいて行われれば開発は加速する。
- プロセスとドメイン開発との相互関係があることによって、このアプローチは「純粋」な設計を単独で扱う、他のどのアプローチよりも実用的になっている。
序文
- 人間の行う入り組んだ仕事を何らかの形で自動化しようとすれば、ソフトウェアはそこにある複雑さを避けて通ることができない。
- できるのはコントロールすることだけである。
- コントロールする秘訣は、優れたドメインモデルにある。
- ドメインモデルの最大の価値
- ユビキタス言語でドメインエキスパートと技術者を結びつけることができるという点
- ドメインモデルは時間と共に進化する
- 最高のアイデアを得られるのはシステムが処理リリースされた後のこと
前書き
- ドメイン駆動設計とは哲学である
- 2003年以前の20年間ドメインモデリングについて重大なテーマであったが、明確に体系化されていない
- オブジェクトコミュニティの底流として、このドメイン駆動設計が誕生した
- この本は、複雑なドメインに直面しているソフトウェア開発チームに向けた、ドメイン駆動設計に体系的に取り組むためのフレームワークを提供する
複雑さという課題
- ソフトウェアがどこまで複雑になれるかを決定する主な要因は、設計に対するアプローチである。
- 手に負えないほど複雑になると、開発者はもはやソフトウェアを十分には理解できなくなり、変更や拡張を容易かつ安全に行えなくなる。
- 優れた設計であれば、複雑な特徴を活用する機会を作り出せる。
- 多くのアプリケーションにおいて、最も重要な複雑さは、技術的なものではない。複雑なのはドメインそのもの、すなわち、ユーザーの活動やビジネスなのである。
- ドメインの持つこの複雑さが設計で扱われないのであれば、基盤となる技術が適切に考えられていたとしても意味がない。
設計対開発プロセス
- エリックエバンスは設計とプロセスは切り離せないと思っている。
- 設計上の概念はうまく実装に落とさなければならず、そうでなければ、無味乾燥な学術的議論になっていしまうため
- 本書のアプローチを行う上での前提条件
XPについて
- 設計上の意思決定が重要である。
- アップフロントの設計には強く抵抗する。
- 変わりにコミュニケーションに対してかなりの労力がつぎこまれる。
- ただ、プロジェクトの対応能力を改善して、進路を素早く変更することが可能である。
- これらの結果として、継続的にリファクタリングを行い、設計上の細かい改善を数多く重ねながら、最終的には顧客の真の要求に適した設計に到達することが可能である。
第1部
ユーザーの活動に置いて有効利用されるソフトウェアを作成するために、開発チームはその活動に関係する体系化された知識を身につけていかなければならない。
そのために、以下の知識を抑える必要がある。
- ソフトウェアのドメイン
- ユーザーがプログラムを適応する対象領域が、ソフトウェアのドメインである。
- ドメインの中には、物理的な世界を含んでいるものもある。
- 例えば、航空会社の予約プログラムのドメインは、実際の航空機に登場する現実の人々を含んでいる。
- 実態を含まないドメインもある。会計プログラムのドメインは金銭と財務である。
- ソフトウェアのドメインは、コンピュータとほとんど関係ないのが普通である。
- モデル
- モデルとは簡素化である。
- つまり、当面の問題を解決する上で関連する側面を抽象化し、それ以外の詳細を無視することによって行われた、現実に対する1つの解釈である。
- また、重荷と格闘するためのツールである。
- 更に言うと、ドメイン知識の圧倒的な情報量と複雑さの中から選びぬかれて、シンプルにされ、意図的に組み立てられた知識の表現形式である。
- ドメインモデル
- 特定の図ではなく、図が伝えようとしている考え方である。
- これはドメインエキスパートの中にある単なる知識ではなく、その知識が厳密に形成され、選びぬかれて抽象化されたものである。
- 図を用いることで、モデルを表現し、伝えることができる。
- ただ、コードでも可能であり、自然言語で書かれた文章でもできることである。
- ドメインモデリング
- モデルをできるだけ「写実的に」作成することはない。
- 目に見える実世界の事柄に関するドメインにおいてさえ、モデルは人為的な成果物にすぎない。
- 必要な結果を出力するソフトウェアの仕組みを構築するだけでなく、ある目的にしたがって、ドメインの概要を表現している。
- 例えば、映画の制作者がドメインモデラに似ている
- ドキュメンタル映画は、未編集の実生活を見せたりはしない。
- 映画の制作者は、体験したことの側面をいくつか選び出し、それらを独特な手法で提示することで、ストーリーを伝えたり意見を主張したりする。
ドメイン駆動設計におけるモデルの有用性
ドメイン駆動設計では、次に示すモデルの3つの基本的用法によって、どのモデルを選択するかが決定される。
- モデルと設計の核心が相互に形成し合う
- モデルとドメインが深く関連すれば最終成果物である実際に動くプログラムに適用されることが保証される。
- この密接な結びつきは保守や継続的開発に役立つ
- モデルは、チームメンバ全員が使用する言語の基盤である。
- 開発者やドメインエキスパートと通訳せずにコミュニケーションが取れる。
- モデルとは、蒸留された知識である。
- モデルはドメイン知識を構成して最も関心のある要素を区別するためのチーム内で取り決めた方法。共有された言語があれば効率的に共同作業ができる。
ソフトウェアの核心
- ドメインに関係した問題をユーザーのために解決する能力がソフトウェアの核心である。
- 技術指向の開発者は、ドメイン知識を勉強することをやめ、ドメインを学んだりモデリングは他人に任せてしまう。
- 技術にフォーカスをしてしまうのだ。
- この開発方法は的はずれなソフトウェアを作ってしまう危険性を秘めている。
- 映画を例に出してみる。
- 1シーンの中で、何回か取り直しを行った。
- 監督がベストだと思うシーンが撮れた。
- しかし、映像編集者は言った。
- 「使えませんよ。誰かがスクリーンへ入ってきたので」
- これは、映像編集者を全うしているのであって、いい映画を作ろうとはしていないということになる。
第一章
知識を噛み砕く
効果的なモデリングの要素
- モデルと実装を結びつける 荒削りなプロトタイプを作ることで、イテレーションを通じてドメインエキスパートとの関係がずっと維持された
- モデルに基づいて言語を洗練させる プロジェクトが進むに連れ、全員がモデルから用語をそのまま取り出し、モデルの構造と矛盾しない文章にまとめて、通訳しなくても正確に理解し合えるようになった
- 知識豊富なモデルを開発する
オブジェクトには、ふるまいと、守るべきルールがある。
モデルは単なるデータスキーマではなく、複雑な問題と解決するのに欠かせないものだった。
モデルは様々な種類の知識を捉えていたのだ。 - モデルを蒸留する
モデルが完成していくにつれて、重要な概念が追加されていった。
それと同様に、役に立たない、核心でないとわかった概念が取り除かれたということがある。
本質的な概念を切り分け、その他の不要なものを削除できるように新たなモデルを探し出した。 - ブレインストーミングと実験を行う
言語をスケッチやブレインストーミングと組み合わせることで、我々の議論の場はモデルの実験室に変わった。
そこでは、モデルの実験用バリデーションを多く使用し、試し、使えるかどうか判断することができた。
チームがシナリオを詳細に検討する際には、会話で使われる表現自体が、提案されたモデルを実現できるかどうかについて調べる簡易的なテストになった。
表現が的確でわかりやすいか、それともぎこちないかを、聞いてすぐに察知することができたからである。
知識の噛み砕き
- 抽象化を行うことから始め、どんどん蒸留させていく
- フィードバックが重要である
- 要は、イテレーティブな開発をすることで、どんどんモデルが洗練されていくのである
継続的学習
- ソフトウェアを書き始めるとき、我々は対象を十分に理解しているわけではない。
- 多くの人々やドキュメントの間に知識が散財しているためである。
- 単純なドメインに騙されるかもしれない。