ドメイン駆動設計 (Domain-Driven Design) 読書会#1
- いずれも役立つソフトウェアを完成させた
- 野心的な目標を達成し、継続的な要求を満たすべく進化しつづけたのは1つだけ
- ドメインモデルなし
- ドメインモデルあり、モデルをコードで表現
- ドメインモデルあり、モデルと実装が分離
- 第１部 ドメインモデルを機能させる
- ドメイン駆動開発の基本的な目標を紹介
- コミュニケーションと設計を推進するためにドメインモデルを使用するとはどういうことか
- 第２部 モデル駆動設計の構成要素
- オブジェクト指向ドメインモデリングにおけるベストプラクティスを要約
- モデルと動作する実用的なソフトウェアの間にある溝を埋める
- モデルと実装を整合させ、互いに補強する状態を維持していく
- 第３部 より深い洞察へ向かうリファクタリング
- 利益をもたらす実用的なモデルを組み立てる課題に挑む
- 素朴なモデル→理解と発見→奥深い設計
- 選択の指針となり得るモデリングの原則を掘り下げる
- 第４部 戦略的設計
- 複雑なシステムやレガシーシステムとの相互作用において発生する状況に対処
- システムに適用される3つ組の原理:コンテキスト、蒸留、大規模な構造
モデル
- 現実の何らかの側面や興味の対象となる概念を表す
- 当面の問題を解決する上で関連する側面を抽象化
- それ以外の詳細を無視
モデルの例：18世紀の中国の地図
- 世界全体を表す
- 中央でスペースの大部分を占めるのが中国
- おざなりに表現された他の国々が周りを囲む
- 世界についてのモデル←国内に意識が向いていた当時の世界観
ソフトウェアプログラム
- それを使用するユーザの何らかの活動や関心と関係
- その対象領域 = ドメイン
- 物理的な世界を含むドメインの例
- 航空会社の予約プログラムのドメイン: 搭乗する人々
- 実体を含まないドメインの例
- 会計プログラムのドメイン: 金銭と財務
- 実体ないと言っちゃっていいのか？
- コンピュータと関係あるドメインの例
- ソースコード管理システムのドメイン: ソフトウェア開発そのもの
適切なドメインモデル
- 情報の持つ意味を明らかにし、その情報を問題に集中させる
- 開発チームは
- モデルをツールとして用い、情報の量と複雑さと格闘
- ユーザの活動に関係された知識を身につける
- ユーザの活用において有効利用されるソフトウェアを作成する
- × 特定の図
- ○ 図が伝えようとしている考え方
- × ドメインエキスパートの頭の中にある単なる知識
- ○ 知識が厳密に構成され、選び抜かれて抽象化されたもの
- 図、慎重に作成されたコード、自然言語で書かれた文章でモデルを表現し、伝えることができる
ドメインモデリング
- × モデルをできるだけ「写実的に」作成すること
- × 必要な結果を出力するソフトウェアの仕組みを構築するだけ
- ○ ある目的に従って、現実の概要を表現
- 実用のために特定のモデルを選択
モデルの3つの基本的用法により、どのモデルを選択するかが決まる
- モデルと設計の核心が相互に形成し合う
- モデルと実装の密接な結びつき
- モデルの理解に基づいてコードを解釈できる→保守や継続的開発において有効
- → 第３章
- モデルは、チームメンバ全員が使用する言語の基盤である
- 通訳せずにドメインエキスパートとコミュニケーションができる
- 生まれながらの言語能力を使ってモデルそのものを改良できる
- → 第２章
- モデルとは、蒸留された知識である
- ドメインの知識を構成して最も関心のある要素を区別するためのチーム内での取り決め
- 概念を分解し関連づける際に、ドメインについてどう考えることにしたか
- → 第１章
ありがちな技術指向の開発者
- 自分の手がける特定のドメインについて勉強する気があまりない
- ドメインに関する作業を面倒と思う
- ドメインを学んだりモデリングしてりするのを他人に任せてしまう
- → 的外れなソフトウェアを作ってしまう危険
モンティ・パイソンの撮影の話
- コメディアンの John Cleese が撮り直したおもしろいシーン
- 映像編集者: コートの袖がスクリーンの端に一瞬見えるので不使用に
- コメディを作るという関心事に対してナンセンス！
- 幸い、監督によっておもしろいシーンは復活した
この本では、ドメインの開発には非常に高度な設計スキルを養う機会があふれていることを示す。
- ソフトウェアドメインにおける混沌とした状況は実は興味深い技術的な課題
- 無秩序なソフトウェアアプリケーションに秩序をもたらすことのできる設計技術を養う
- 最初はなじみのないドメインにおいてさえも、開発者ははるかに価値のある存在となる
- プリント基板設計用の専門ソフトウェアツールの設計をすることに
- 「私」は電子機器について何も知らなかった
- このソフトウェアを作成するのに十分なくらい電子機器について理解するには？
- 納期が来る前に電子技術者になることなどできるはずもない
- 「彼ら」は素晴しい回路設計者
- 生産性を飛躍的に向上するソフトウェアを設計できるのは「私」
さあどうする？
- 帳票にいつでも現れる「ネット」に着目
- 「私」はオブジェクトの相互作用図のようなものを描いて説明
- 「彼ら」はしきりに「私」の言うことを訂正
- 用語法にあった不一致やあいまいさ、技術的な見解の相違を一緒になって解決
↓
- 「私」にも知識が身につき始めた
- 「彼ら」は物事をより厳密に矛盾なく説明してくれるようになった
↓
- 調査の焦点を絞る→特定の機能に注目
- それと関係ない事柄を省く
- ブレインストーミングとモデルの改良を繰り返し
↓
- モデルを反映した具体的なプロトタイプを作成
- モデルの意味、機能するソフトウェアとの関係をドメインエキスパートが明確に理解
- 新しく獲得した知識を「私」がどのようにモデル、ソフトウェアに組み込んでいくかを「彼ら」が理解
- ソフトウェアの専門家が図を見れば、ソフトウェアの内容を理解できるように
↓
- PCB技術者とより円滑にコミュニケーションしたりするためのフレームワークができた
- モデルオブジェクトを用いて新しい機能を説明
- 説明できないときはオブジェクトモデルを変更して知識をかみ砕き
- モデルを改良すると、コードも一緒に進化
成功につながった理由
- モデルと実装を結びつける ... 本質的な結びつきが早い時期に作り出され、以後維持された。
- モデルに基づいて言語を洗練させる ... 通訳しなくても理解しあえるように
- 知識豊富なモデルを開発する ... オブジェクトのふるまい、守るべきルール
- モデルを蒸留する ... 本質的な概念を切り分け、不要な概念を削除
- ブレインストーミングと実験を行う ... 議論の場はモデルの実験室に
知識をかみ砕くことで、チームの持っている知識が価値のあるモデルへと変わる。
知識のかみ砕き
- 開発者とドメインエキスパートからなるチームが共同して行う
- たいていは開発者が率いる
- 情報を引き出し、それをかみ砕いて役に立つかたちにする
- 初期のバージョンやプロトタイプでの経験がチームにフィードバックされて、解釈が変わっていく
ドメインモデルを絶えず改良することによるチームメンバ間のやりとりの変化
- 開発者: 自分が力を貸しているビジネスにおける重要な原理を習得するよう強いられる
- → 機械的に機能を作り出すことがなくなる
- ドメインエキスパート: 自分の知っていることを蒸留して本質を抽出するよう強いられる
- → ソフトウェアプロジェクトが必要とする概念の正確さを理解する
ソフトウェアを書き始める時、我々は対象を十分に理解しているわけではない。
高度に生産的なチームは、継続的学習を実践する。
- 一般的なドメインモデリングのスキルの向上 (e.g. この本の内容)
- 技術的な知識を向上
- その時に取り組んでいる具体的なドメインについて真剣に学習
↓
自ら学んだチームメンバは、最も重要な領域を含む開発作業に集中するにあたり、コアとなる。
かみ砕いた知識を反映したモデル →そのモデルを表現するべく実装をリファクタリング
例: ある船の一回の航海に対して、貨物を運んでもらうように予約するアプリケーション
10%のオーバーブッキングを認める。 → ポリシー (as ストラテジーパターン)
関係者の誰もがオーバーブッキングの本質を理解
- × 単なるわかりにくい計算
- ○ 明確で重要なビジネスルール
プログラマがビジネスエキスパートに成果物を見せることでフィードバックループが完結
役立つモデルがすぐに見つかる表層にあることはめったにない。 ドメインとアプリケーションがやるべきことを我々が理解するようになるにつれ、
- 最初は重要と思われたモデル要素を廃棄
- モデル要素を違った視点で見る
- → 問題の核心を付くようなうまい抽象が現れてくる
知識のかみ砕きは探求であり、最終的に行き着く先はわからない。