エリック・エヴァンスのドメイン駆動設計: ソフトウェアの核心にある複雑さに立ち向かう
- 翔泳社 (2011年4月1日発売)
本棚登録 : 949人
感想 : 34件
- Amazon.co.jp ・本 (538ページ)
- / ISBN・EAN: 9784798121963
感想・レビュー・書評
-
現時点で、ソフトウェア開発の設計について、ここまで体系的にまとまっているものはないと思う。DDDの素晴らしい点は、こうして体系だてられることで、チームの依り代となる点だと感じる。
（Evansの）DDDは大きく二つの柱からなる。
ひとつは、オブジェクト指向ベースのより人間が理解しやすいモデリングを追求するという点。これは、例えば、誕生日という概念があるときLocalDateとして扱うよりも、DateOfBirthとしてモデル化した方がより責務が明快になる。ビジネスにおける重要な関心事に集中して明快に要約したものをモデル化することで、ビジネスの変化に対応しやすくなる。（多くの場合、開発サイドで独自の言葉でコードにしがちだが、そうするとビジネスサイドと会話が噛み合わないことが増えていく。）
もうひとつは、XPの考え方を取り入れることで、変化を受け入れ適応していく開発スタイルである点。XP第二版の翻訳が出たばかりではあるが、それを読むと必ずアジャイル手法をとらなければいけないわけではないことが分かる。ウォーターフォールであっても、うまくコミュニケーションをとりえれば、XPを持ち込むことができるとある。DDDではこのXPの価値、原則を取り入れ、変化と設計をどう結びつけるかを論じている。また、複数のサービス、チームに分かれる場合の戦略など、より大きな視点も含まれていることが素晴らしい。
これから益々、DDDの知名度は上がっていくと予想されるので、必読の一冊となるだろう。
0
詳細をみるコメント0件をすべて表示 -
Domain Driven Design(DDD)についての名著。ポイントになるのは、ユーザと開発者が同じ言語を用いて、それをモデル分析や設計、実装に渡って全般的に使用すること（ユビキタス言語の使用）という観点。業務領域（ドメイン）で使われる言語によって分析・設計・実装を行うことにより、当のシステムを開発する視点がブレなくて済むし、開発の各段階でのミスコミュニケーションも減る。システムは業務上の問題を解決するために構築されるものであるから、その設計はドメインに対するモデルを作ることに主眼を置く。ドメインモデルはつまり、業務領域における概念分析になる。本書ではそれはクラス図を用いて行われるが、それはユースケース図でも、UMLを用いない形でも可能だろう。ユーザが理解できさえすればコードそのものでも構わない。ただし、DOAは明らかにこれになじまない。
本自体は大きいが、DDDの実際のポイントは最初の3章ほど。後はいかにドメインに注目して分析を進めていくかのデザインパターン集になっている。UI、アプリケーション、ドメイン、インフラという基本的な4つのレイヤー構造、エンティティ・値オブジェクト・サービスといった構成要素、ドメインにおける重要な制約や条件を分離するための仕様やストラテジーといったところが面白かった。また複数のドメイン間の関係や大規模なものになったときにそれぞれを分離するための戦略的パターンも、おぼろげながら実際に取られているものだろう。
これを実際のプロジェクトで使うのは（日本では？）たしかにけっこう困難だ。まずもってユーザへの負荷が大きい。DDDのポイントやいくつかのデザインパターンについては理解してもらわなければならないし、反復的開発においてドメインモデルの深化を行うには長期に渡って時間を割いてもらわなければならないだろう。エンジニア側が複数チームだった時、ユーザ相互に認識の相違があった時、どう調整すればいいのか。プロジェクトとしての進捗管理はどうするのか。見積もりは？成果物は？とはいえ、既存の開発手法にも取り入れられるところは多いので使えるところはありそうだ。
0
-
京都で読書会をやってました。
序盤のDDDの基礎的な部分も面白いが、後半の実践するための様々な手引き部分が業務とリンクしてとても読み応えがある。
ただ、モデリングを始めようとして手に取ると、モデリング手法については一切触れていないので不完全燃焼になるかも。
この本はあくまでもモデリングができる前提で、モデルを利用した開発の仕方を説明している本なので注意が必要。
0
-
howtoより啓蒙本かなぁ
経験してないと腑に落ちない気がする
ユースケースドリブンとは併用できなそう
強いアーキテクチャ制約を課すとDDDの良さは出なそう
アジャイルというかイテレーション開発が受け入れられるか、お客さんのスキルレベルと参画度合いにDDD実現のキモと言えそう
0
-
難しい言い回しもあり、理解出来ない点もあったが、
共感でき、役に立つ部分も結構あり。
またしぱらくたって、読みなおせば違った収穫がありそう？
0
-
面白い。久しぶりにソフトウェア工学の本を面白いと思った。90年代に『実践UML』を読んで以来。これはITアーキテクトではなくIAの視点でも面白い。
読みやすい構成、読みやすいデザイン。太字強調や細かい見出し設定のおかげでさくさく読める。パターン・ランゲージで書かれている。
当初は「これはIAの役に立つ手法だが、IA自身が勉強すべきことではない。エンジニアがIAや顧客（ドメインエキスパート）の言葉でモデリングできるようになればいいだけだ」と考えていた。
しかし、それはもったいない考え方だった。以下の文章で示されるような「オブジェクト指向UI (OOUI)」の発想からDDDを捉えるとどうだろう。そこにはドメインエキスパートとエンジニアの間で、IAやUIデザイナ自身もまたDDDを活用してモデリングしているという未来像が想像できないだろうか。
> GUI とオブジェクト指向の間には強い繋がりがあると確信していた僕でしたが、その関係性をもっと直接説明した資料はないかと思って調べたところ、それほど多くはないものの、いくつかの文献に行き当たりました。
> 合理的ではあるものの、操作方法がなんだかとても「手続的」で、機能要件をそのままコントロールに割り当てただけのような感じがするのです。結局、タスク指向に引き寄せられているのです。
> 考えてみればそれもそのはずで、OOA でモデル化されるのはあくまでもユーザーの要求事項と因果関係だけなので、それらを秩序だったひとつの道具としてまとめる世界観は、ユーザーの想像の域を出ないのです。これは決定的な弱点です。
> OOUI | Modeless and Modal http://modelessdesign.com/modelessandmodal/2009/10/29/ooui/
> 複雑性は減らすことができないわけですから、操作性を高めるためには、複雑性の一部をユーザーサイドからシステムサイドに移動してやる必要があります。
> どのように操作しても、左右のオブジェクトが常にイコールになるようになっており、「入力内容をメモリにバッファしてサブミットする」というシーケンシャルなフローを排除することに成功しています。もはやそこでは、「通貨を換算する」というタスクはデザインに対して拘束力を持たず、「左右のオブジェクトが互いにイコールになろうとする」というオブジェクト同士の静的な性質があるだけです。ユーザーはその性質を利用しながら自由な方法で目的を達成できるのです。
> ほとんどの設計者は、明文化された要件の中から「必要な入出力情報」を抽出し、それを「操作の手順」としてリニアライズしようとしてしまいます。その結果出来上がるのは「穴埋め式」のようなミニウィザードです。しかしUIをモードレスにするためには、「必要な入出力情報」を抽出した後は、「複雑性」の一部をシステムサイドに移動するような「オブジェクトの性質」を検討しなければならないのです。
> 要求全体をひとつのシンプルな世界観にまとめるためには、このような「要件として明文化はされていないけど出来てしまう事」を出来なくする方が難しいのです。これはむしろ、要件が持っていた「いびつさ」をデザインが矯正したと言えます。要件に対して過不足の全く無いデザインを無理に作っても、シンプルな世界観に落とし込めないのなら、それはユーザーにとっても理解しづらいものである可能性が高いのです。多少要件を拡大解釈することになっても、この模範回答のように、それによってデザインをシンプルかつ合理的にできるのであれば、そうするべきなのです。結果的に、画面数は1になっているのです。
> 複雑性をシステムサイドに移動させるには、UIをモードレスにして、「タスク選択」という課税的な操作を「オブジェクト選択」の操作に同化させてしまうのが有効です。そのためには、明文化された要求事項から「タスクの手順」を探るのではなく、「オブジェクトの性質」を探らなければならないのです。そして、出来上がったデザインが事前に定義した要件と異なるスコープを持っていたとしても、結果的にそれが役立つなら、それを受容するべきなのです。何かをデザインとは、そういうことではないでしょうか。
> Complexity | Modeless and Modal http://modelessdesign.com/modelessandmodal/2009/12/22/complexity/
> このような、「一応便利に使えはするけどイマイチなデザイン」について、僕はどのように評価すればよいのか迷います。ただ、それが目指すべき理想のデザインでないことは確かです。
> 問題は恐らく、UCD/HCD のメソッドが、RUP と同様に、ユーザーのタスク（業務）を拠り所としていることにあります。ユーザーの要求を知ろうとすることは確かにシステムの有効性を高めるために必要だと思いますが、ユーザー（コンテクスト）の多様性を考えると、タスクをベースにしてデザインされたシステムは、モーダルで非効率で学習しづらいものになってしまうのです。
> そのようなタスク指向のデザインメソッドに対するカウンターパートとして、OVID に代表されるオブジェクト指向デザインのプロセスがあります。
> オブジェクト指向デザインのメソッドでは、OOA/OOD で行うオブジェクト分析の結果を流用できます。すなわち、ユーザーの関心の対象であるオブジェクトをクラスとして定義し、それをそのままスクリーンに登場させるのです。またその結果として、モデル層のオブジェクトとビュー層のオブジェクトが比較的自然に対応するようになり、アルゴリズムの見通しも良くなるはずです。
> プログラム設計のためのクラス定義では、ユーザーのメンタルモデルには関係しないような抽象度の高いクラスやコントローラーのためのクラスなどが必要ですが、OOUI ではそれらは無視して、ユーザーにとって意味のあるクラスだけをUI上のオブジェクトとして表現します。
> 開発メソッドにおいてオブジェクト分析の手法が確立されているのに、それがUIに適用されていないのは、RUP に代表される標準的プロセスがタスク指向であるからだと前に書きました。しかしタスクを包括してクラスの性質を定義するというロジックの飛躍を許容するならば、モードレスなデザインもある程度メソッド化することが可能だろうと思います。その飛躍部分をノウハウとして整理するのが、デザインパターンの役割というわけです。
> UIを通じて「ユーザーが行えること」を決定するのはオブジェクトのクラスであり、その性質（プロパティとメソッド）です。つまりユーザーが接するクラスの性質を定義することが OOUI デザインの中心的作業になります。
> Counterpart | Modeless and Modal http://modelessdesign.com/modelessandmodal/2010/01/05/counterpart/
追記：2013年2月12日 再読完了。
p.12 永続化もUIもない、ドメインだけのコード。テスト駆動で。
コードに、ドメインエキスパートと開発者が共有するモデルが反映される。
動くコードによって、ドメインエキスパートとの議論が活発になる。
→いきなりウォーキングスケルトンとエンドツーエンドテストから書き始めるより、最初はドメイン層だけをテスト駆動開発することでドメイン言語を成長させた方が良いと思った。ドメイン知識が足りない時にアーキテクチャ全体を固定すること自体がBDUFな気が。
p.470 責務のレイヤー
- 意思決定支援
- ポリシー
- 確約
- 業務
- 潜在能力
> システムのそういう部分（※引用注：技術的なインフラストラクチャや、特別なドメインの知識がなくても理解可能な、うまく限定できるドメインに関する問題）は、コンピュータ科学者の関心を引くらしく、**他でも使える専門スキルを構築して、履歴書を書く時のいい材料になると考えられている**。特化したコアは、アプリケーションを実際に差別化してビジネスの資産とするようなモデルの部分であるのに、それほどスキルのない開発者によってまとめられることになるのが通例である。そういう開発者は**データベース管理者と協力してデータスキーマを作成し、モデルの持つ概念の力を一切利用することなく1機能ずつコードを書く**。（p.408-409）
> 純粋に技術的な課題は、通常、才能のあるソフトウェアエンジニアにとって最も興味深くやりがいがあるように見えるものだが、ドメイン駆動設計によって開かれる新しい挑戦の領域は、少なくともそれに匹敵する。ビジネスソフトウェアを作るのに、混沌としたものをボルトでつなぎ合わせるようにする必要はない。**複雑なドメインと格闘して、わかりやすいソフトウェア設計にすることは、優秀な技術者にとって刺激的な挑戦なのだ。**（p.511）
0
-
---2011/7/15---
とりあえず１回読みました。
ズバリ今の私には非常に有益な本でした。
オブジェクト指向の開発経験が乏しい私にはピンと来ず、すんなり理解できない箇所もあったので、この先繰り返し読もうと思います。
筆者が関わったプロジェクトの様々な失敗の様子も記載されているのもよいです。
それらが自分の会社の状況と非常に似通っており、ちょっと気が重くなったりもします。
ドメイン駆動開発、モデル駆動開発、オブジェクト指向での開発をしていない方にも役立つ内容がたくさんあると思います。
記載されている内容を自分のプロジェクトと組織に合わせ、実践できるようになりたいです。
0
和智右桂の作品
