Domain-Driven Design

ドメイン駆動型デザインとは何か？

　最近の十年から二十年間にかけて、一つの哲学が、オブジェクト・コミュニティーの中の底流として発展してきた。

　ドメイン駆動型デザインの前提は２つある：
　　・たいていのソフトウェア・プロジェクトについて、主要な焦点はドメインおよびドメインロジックにあるべきだ
　　・そして、複雑なドメイン設計はモデルを基にすべきだ

　ドメイン駆動型デザインは、技術でも方法論でもない。それは複雑なドメインに対処しなければならないソフトウェア
・プロジェクトの促進を目指した、一つの考える方法、あるいは、一まとまりの優先事項といったものだ。
　そのゴールを達成するために、チームは、設計のプラクテイス、技術および方針の広範囲なセットを必要とする。こ
うした技術を洗練させ、適用することが、このサイトでの議論の主題になるだろうが、Eric EvansのDomain-Driven
Designに載っているパターンの言語から始めることが多くなるだろう。

複雑さの挑戦

　もちろん、プロジェクトの方向を狂わせてしまう要因は多く、官僚政治、不明瞭な目的、資源の不足などがすぐ挙げ
られる。だがこれは、ソフトウェアがどれだけ複雑なものになるうるかを大枠で決定する設計というものに対してのアプ
ローチなのだ。複雑さが手に負えなくなる場合、ソフトウェアはもはや十分にうまく理解することができず、容易に変更
も拡張もできなくなる。対照的に、よい設計は、そうした複雑さの中からでも、変更の可能性を生み出せる。
　これらの設計の要因のうちのいくつかは技術的なものなので、ネットワーク、データ・ベースおよびソフトウェアの他の
技術的次元の設計に多くの努力がはらわれてきた。こうした問題を解決する方法に関する本が書かれてきた。開発者
はスキルを磨いてきた。
　しかし、多くのアプリケーションにおいて、最も顕著な複雑さは技術的なものではない。それは、ドメインそのもの、ユ
ーザの活動あるいはビジネスにある。このドメインの複雑さが設計において考慮されない時、インフラストラクチャーの
技術がうまくできていようが何もならなくなってしまう。うまくいく設計は、ソフトウェアのこの中心的な側面に対処しなけ
ればならない。

Download draft of book from
http://www.domaindrivendesign.org/book/DDD_2003-04-15.pdf
http://www.domaindrivendesign.org/

Examples (code)

Coming soon...じゃ話にならんのですよ！！はい！
考え直させてください！！実家に帰らせてもらいます

　ソフトウェア開発を複雑にするのには多くの要因がある。が、複雑さの中心になるのは、問題領域自体の本質的な複雑さ
である。複雑な人間からなる企業にオートメーションを加えようとするのなら、ソフトウエアはこの複雑さを避けることは
できない−それをコントロールすることができるのみだ。
　複雑さをコントロールするための鍵は、よいドメインモデルである。ドメインの表面的な見かけを越えて、根本の構造を
導入するモデルは、ソフトウェア開発者に必要な手段を与える。よいドメインモデルは信じられないほどに価値がありえる
が、作ることが容易なものではない。ほとんどの人々はうまくできず、また教えるのは非常に難しい。
　エリック・エヴァンスは、よいドメインモデルを作成することができる少数のうちの一人だ。私は彼と一緒に働いてみて
それを発見した。クライアントが自分よりもより熟練しているのを見つける素晴らしい機会のうちの１つ。私たちの共同作
業は短いが巨大な楽しみだった。その時以来、私たちは連絡をとり続け、私はこの本がゆっくり懐胎するのを見た。それは
待つ価値があった。
　この本は、巨大な野心を満足するものへと発展した：ドメインモデリングのアートそのものについて記述し、また、その
ための用語を構築すること。この学びがたいスキルを教えるのと同時に、この行為について説明することができるレファレ
ンスの構造を提供すること。この本は、多くの新しく形作られたアイディアを私に教えてくれた。概念モデリングの熟練者
でも、この本を読むことで多くの新しいアイディアを思いつかないとしたら驚きだ。
　エリックはまた、私たちが数年にわたり学習してきたものの多くを接合する。最初に、ドメインモデリングでは、実装か
ら概念を分けてはならない。良いドメインモデル製作者は、会計係とホワイトボードを使用することができるだけでなく、
プログラマとJavaを書くことができる。このことが真実であるのは、部分的には、実装の問題について熟慮することなしに、
有用な概念のモデルを構築することができないことによる。しかし、概念と実装を一緒に扱わなければならない第一の理由
は：ドメインモデルの最大の価値は、それがドメインエキスパートと技術者とを結ぶ、a ubiquitous language を提供する
ことにあるからだ。

　この本から学ぶもう一つのレッスンは、ドメインモデルは、最初にモデル化され、次に、インプリメントされるものでは
ないことだ。多くの人々のように、私は、「設計し、後に、構築する」段階的な考えを拒絶するに至った。しかし、エリッ
クの経験によるレッスンは、真に強力なドメインモデルは時間とともに発展することであり、最も経験を積んだモデル製作
者さえ、システムの初期のリリースの後に最良の考えを獲得することを知るということだ。私は、この本がとてつもなく影
響力のある本になると思うし、そう希望する。有用なツールを使う方法を多くの人々に教えている一方で、ひどく滑りやす
いこのジャンルへ、構造と結合を加える一冊になるだろう。ドメインモデルは、ソフトウェア開発をコントロールする上で、
大きな成果を導き出すことができる−そのインプリメントされている言語や環境が何であれ。
　最後になるが、重要だと思うことがある。私がこの本で最も尊敬することの一つは、エリックが成功しなかった時のこと
を話すことを恐れないことだ。ほとんどの著者は、公平で全能な雰囲気を維持したがるものだ。エリックは、私たちのほと
んどがそうであるように、成功と失望の両方を彼が味わっていることを明らかにする。重要なことは、彼が両方から学習す
ることができることであり、私たちにとってより重要なのは、彼にそのレッスンを伝える能力があることだ。

お前馬鹿か。小学校からやり直せ。

> ドメイン駆動型デザインとは何か？
>
> 　最近の十年から二十年間にかけて、一つの哲学が、オブジェクト・コミュニティーの中の底流として発展してきた。

「とは何か？」って書いておきながら、概要は後回しで具体的説明に入るのか。
そのドメイン駆動型デザインとやらを知らない人間がその説明を読んでも
文章が無闇矢鱈に長い上に話の順番が小学校の作文レベルで理解できないし、
理解してる人間がいても基礎的な概念の説明しかしてないから読む価値が無い。
お前みたいなのと一緒に仕事してる奴が可哀想だ。
周囲に無駄な迷惑掛けないようにもう少し考えて行動しろよ。クズ

基礎を再構築しようとする、いい本だあよ

概念の売込みで食える時代は終わった

DQN駆動型デザインとは何か？

　最近の十年から二十年間にかけて、一つの哲学が、２ちゃんねる・コミュニティーの中の底流として発展してきた。

　DQN駆動型デザインの前提は２つある：
　　・たいていのソフトウェア・プロジェクトについて、主要な焦点はDQNクライアントおよびDQNＳヨの駆逐にあるべきだ
　　・そして、複雑なDQN設計はモデルを基にすべきだ

・多数の複雑なDQN設計は、わからないまま過去に手がけたプロジェクトのモデルを基にしているため、そのＤＱＮにしか理解できない。
したがって、これがそのＤＱＮが生き残るための手法になる。

ＤＱＮ駆動型デザインは、技術でも方法論でもない。それは複雑な要求、技術に対してＤＱＮがプロマネになってしまったソフトウェア
プロジェクトの促進を目指したと言い訳できる方法であり、そのＤＱＮの優先事項といったものだ。

水晶玉に難解な用語を撒き散らして弾幕をはりながら
デスマ懸念プロジェクトから退却するコンサルの姿が
見えます

Preface to Domain-Driven Design
by Eric Evans

　主要なソフトウェア設計者達は、少なくとも二十年間、ドメインモデリングおよびデザインを重大なトピックと認めてきた
が、何が為される必要があるか、また、それを行う方法に関して、驚くほど何も書かれてはこなかった。明確に公式化さ
れてはいない、一つの哲学が、オブジェクト・コミュニティーの中の底流として出現した。この哲学を、私はドメイン駆動型
デザインと呼ぶ。
　私は、いくつかのビジネスおよび技術的なドメインで、複雑なシステムを開発することに、過去十年間を費やした。その
中で、オブジェクト指向開発のリーダー達が発展させた、設計および開発プロセスでの最良のプラクティスを試みた。私の
プロジェクトのいくつかは非常に成功し、少数が失敗した。成功に共通の特徴は、設計の反復によって改良され、プロジ
ェクト構造の一部になった豊富なドメインモデルだった。
　この本は、デザイン上の決定を下すためのフレームワークと、ドメイン設計について議論するための専門語彙を提供する。
これは、私自身の洞察、経験と、広く容認された最良のプラクティスとの合成である。複雑なドメインに直面するソフトウェ
ア開発チームは、ドメイン駆動型デザインに系統的にアプローチするためにこのフレームワークを使用することができる。

３つのプロジェクトを対照させること

　３つのプロジェクトが、ドメイン設計の実践がどれだけ劇的に開発結果に影響することができるかの鮮明な例として私の
記憶に残っている。３つのプロジェクトはすべて有用なソフトウェアを完成させたが、１つだけが野心的な目的を達成し、
組織の引き続くニーズを満たせるように進化し続ける複雑なソフトウエアを作り出した。

　私が見た１つのプロジェクトは、有用で単純なウェブ・ベースの取引システムを開発し、ゲートを素早く抜けた。開発者は
勘でやっていたが、それでもこれだけ単純なソフトウェアなら、設計にほとんど注意を払わなくても書くことができた。この
初期の成功の結果、将来の開発への期待は非常に高かった。この時点で私は第二バージョンに取り組むよう依頼された。
よく見ると、彼らはドメインモデルやプロジェクト上の共通語さえ欠き、非体系的な設計を抱えていることがわかった。プロ
ジェクト・リーダーは私の評価に賛成しなかったので、私は仕事を断わった。１年後に、チームは身動きができなくなり、第
二バージョンを完成させられないことに気づいた。彼らの技術の使い方も模範的なものではなかったが、彼らを打ち負かし
たのはビジネス・ロジックだった。彼らの最初のリリースは、高いメンテナンスの遺産（レガシー）へと、成熟しないままに
化石化した。
　この複雑さの限界を上に伸ばすためには、ドメインロジックのデザインへのもっとまじめなアプローチが要求される。私の
初期の経歴において、ドメイン設計に重点をおいたプロジェクトに携われたのは幸運だった。このプロジェクトは、最初にあ
げた例と少なくとも同じくらい複雑なドメインの中で、適度の初期の成功で始まり、機関投資家のためのシンプルなアプリ
ケーションを完成させた。だがこの場合は、初期リリースに続いて、継続的な開発が続けられた。各反復は、前のリリース
の機能性を統合し磨きをかけるための、刺激的な新しい選択肢を追加した。チームは、投資家のニーズに対して、柔軟性
と拡張可能性を持って応答することができた。この上向きの軌道は、繰り返しリファインされ、コードとして表現されたドメイ
ンモデルに直接起因した。チームがドメインに対する新しい洞察力を獲得するとともに、モデルは深みを増した。 コミュニケ
ーションの質は、開発者間だけでなく、開発者とドメインエキスパートとの間でも改善し、デザインは、より重いメンテナンス
の負担となるどころか、より修正と拡張が簡単なものになっていった。

　不幸なことに、プロジェクトは、ただモデル化をまじめにやるというだけでは、このような聖なるサイクルには到達しない。
私の過去の１つのプロジェクトは、ドメインモデルに基づいたグローバル企業システムを構築するという高い目標とともに始
められたが、数年間の失望の後に、目標を低下させて、慣習的な方法をとることに落ち着いた。チームはよいツールを持ち、
ビジネスをよく理解していた。そして、モデリングにも細心の注意をはらった。しかし、インプリメンテーションとモデリングを
分離するという、まずいやり方で開発者の役割分担をしてしまったために、デザインは、進められていた深い分析を反映し
なかった。ともあれ、詳細なビジネス・オブジェクトのデザインは、精巧なアプリケーションを組み合わせるのを支援するほど
には十分に頑丈ではなかった。イテレーションを繰り返してもコードは改良されなかったが、これは開発者間のスキルレベ
ルの不均等さによるものだった。彼らは、実際に走るソフトウェアとしても機能する、モデルに基づいたオブジェクトを作成す
るための、定式化されていないスタイルとテクニックがあることを知らなかった。月日が経過するにつれ、開発作業は、複雑
さの中で泥まみれになり、チームはシステムに密着したビジョンを失った。数年の努力の後に、プロジェクトは適度に有用
なソフトウェアを生み出したが、チームはモデルにフォーカスするのをあきらめ、初期の野心を放棄した。

複雑さの挑戦

　プロジェクトの方向を狂わせてしまう要因は多く、官僚政治、不明瞭な目的、資源の不足などがすぐ挙げられる。だがこれ
は、ソフトウェアがどれだけ複雑なものになるうるかを大枠で決定する設計というものに対してのアプローチなのだ。複雑さ
が手に負えなくなる場合、ソフトウェアはもはや十分にうまく理解することができず、容易で安全に変更も拡張もできなくな
る。対照的に、よい設計は、そうした複雑さを飼い慣らす機会を生み出せる。
　これらの設計の要因のうちのいくつかは技術的なものなので、ネットワーク、データ・ベースおよびソフトウェアの他の技術
的次元の設計に多くの努力がはらわれてきた。こうした問題を解決する方法に関する本が書かれてきた。多数の開発者は
スキルを磨き、個々の技術的な進歩に追いついてきた。

　しかし、多くのアプリケーションにおいて、最も顕著な複雑さは技術的なものではない。それは、ドメインそのもの、ユーザ
の活動あるいはビジネスにある。このドメインの複雑さが設計において考慮されない時、インフラストラクチャーの技術がうま
くできていようが何もならなくなってしまう。うまくいく設計は、ソフトウェアのこの中心的な側面に対処しなければならない。
　この本の前提は２つある：
　　１．たいていのソフトウェア・プロジェクトについて、主要な焦点はドメインおよびドメインロジックにあるべきだ
　　２．複雑なドメイン設計はモデルを基にすべきだ
　ドメイン駆動型デザインは、複雑なドメインに対処しなければならないソフトウェア・プロジェクトの促進を目指した、一つの
考える方法、あるいは、一まとまりの優先事項といったものだ。そのゴールを達成するために、この本は、設計のプラクテイ
ス、技術および方針の広範囲なセットを提供する。

デザイン対開発プロセス

　デザインの本。プロセスの本。それらは互いにめったに相互参照しない。各トピックはそれ自身が十分に複雑だ。これはデ
ザインの本だが、私は、デザインとプロセスとが切り離せないものだと信じる。デザインの概念は、成功裡にインプリメントで
きるものでなければならない。でなければ、それらは干からびた学術的な議論でしかない。
　デザインのテクニックを学ぶと、だれでもその可能性に興奮を覚えるが、リアルなプロジェクトのやっかいな現実は、不意に
襲ってくる。使用しなければならない技術に、新しいデザインのアイディアを合わせられない。あるいは、時間との兼ね合い
で、ある特定のデザインの側面をあきらめるべきなのか、または立場を固守してクリーンな解決を見つけるべきなのかがわ
からない。開発者達は、デザインの指針の適用について互いに抽象的に話したりすることが多いが、リアルな問題がどう解
決されるかを話す方がより自然である。だから、これはデザインの本であるが、私は必要な場合は、その人工的な境界を横
切ってプロセスに口を出すだろう。デザインの指針をコンテクストの中に置く助けになるはずだ。

　この本は特定の方法論に結び付けられてはいないが、"Agile development processes”と呼ばれる一群の新しい方法論
を指向している。特に、以下のプラクティスが、プロジェクト上で行われていると仮定する。この２つのプラクティスは、この本
のアプローチを適用するための先行条件である。
１．反復型の開発であること。
　反復型の開発はこの数十年の間に主張され実行されてきた。そしてそれは、"Agile development processes" の基礎で
ある。"Agile development"と"Extreme Programming(or XP)"の文献によい議論が成されているものが多く、その中でも、
Surviving Object-Oriented Projects (Cockburn 1998) や Extreme Programming Explained (Beck 1999) がよい。
２．開発者とドメインエキスパートとが密接に協力しあうこと。
　ドメイン駆動型デザインは、巨大な量の知識をかみくだいて、ドメインに対する深い洞察を反映するモデルを作り、キーコン
セプトに焦点をあてる。これはドメインを知っている人々と、ソフトウェアを構築する方法を知っている人々との共同作業であ
る。開発は反復するので、この共同作業はプロジェクトのライフサイクル全体にわたって継続しなければならない。
　Kent Beck、Ward Cunningham その他(Extreme Programming Explained [Beck 2000]参照) によって作られた Extreme
Programmingは、Agile processes の中で最も顕著なものであり、私もこれを使うことが一番多い。この本の全体にわた
って、説明を具体的にするために、私は、デザインとプロセスとの相互作用の議論のための基礎としてXPを使うつもりだ。
絵入りの法則は、他の Agile processes に容易に移植できる。
　近年、役に立たない静的なドキュメントおよび強迫的な事前の計画と設計により、プロジェクトに負担を負わせる緻密な方
法論に対する反乱があった。これとは違い、XPのような Agile processes は、変更と不確実性に対処する能力を重視する。
　Extreme Programmingは、デザインにおける決定の重要性を認識しているが、事前の計画と設計には強固に反対する。

代わりに、それはコミュニケーションと、コース変更をすばやく行えるようにプロジェクトを改善することに努力を注ぐ。変化に
反応できることで、開発者は、プロジェクトの任意の段階で、”動作する最も単純な解”を使うことができ、その後、連続的な
リファクタリング、多くの小さな設計改良によって、最後には、顧客の真のニーズに適合するデザインに到達する。
　このミニマリズムは、過剰にデザインに入れ込む人々への、まさに必要とされた解毒剤だった。プロジェクトは、ほとんど価
値のない厄介なドキュメントで身動きがとれなくなっていた。不完全な設計を非常に恐れるチームメンバーにより、全く進歩
がなくても設計作業を続ける「分析麻痺」にかかっていた。何かが変わらなければならなかった。
　不運にも、これらのプロセスのアイディアのいくつかは誤解されやすい。各人は、"一番簡単な解"についての異なる定義を
持っている。連続的なリファクタリングは一連の小さなデザイン変更である、が、しっかりした設計方針のない開発者は、ひど
くわかりずらく変更の難しいコード・ベースを生みだす−これは agility の反対だ。また、予想外の要件に対するの恐れは過
剰な作り込みにしばしば結びつくが、過剰な作り込みを回避する試みは別の恐れへ発展する：設計に関して深く考えること自
体に対する恐れ。
　実際、XPは、鋭いデザインセンスを持った開発者のために最良に働く。XPプロセスは、開発者がリファクタリングによって設
計を改善することができ、これが何度も素早く行われると仮定する。しかし、過去のデザインの選択は、リファクタリング自体
をより容易にも困難にもする。XPプロセスは、チームのコミュニケーションを良くしようとする。が、モデルとデザインの選択は
コミュニケーションを明確にも混乱したものにもしてしまう。
　この本はデザインと開発のプラクティスを絡み合わせて、ドメイン駆動型デザインと Agile development がどのように互いに
強化するかを例証する。Agile development process のコンテクストの中でのドメインモデリングへの精巧なアプローチは、開
発を加速するだろう。プロセスとドメイン開発の相互関係は、このアプローチをどんな純粋なデザインの真空中の話よりも実
用的にする。

この本の構造

　この本は４つの主なセクションに分割される：
　パートI：　ドメインモデルを働かせること
　　　ドメイン駆動型デザインの基礎的な到達目標を示す；これらの到達目標は、後のセクション中のプラクティスを動機づけ
　　る。ソフトウェア開発には非常に多くのアプローチがあるため、 パートI では用語を定義し、コミュニケーションとデザインの
　　ためにドメインモデルを使用することの意味の概観を与える。
　パートII：　モデル駆動型デザインのビルディングブロック
　　　オブジェクト指向のドメインモデリングでの最良のプラクティスのコアを、ひと揃いの基礎的なビルディングブロックへと凝
　　縮する。このセクションは、モデルと実際に動くソフトウェアの間のギャップを埋めることを中心に置く。これらの標準的なパ
　　ターンを共有することは、設計に秩序をもたらす。チームメンバーはより簡単に他のメンバーの仕事を理解する。標準的な
　　パターンの使用はさらに、共通言語（モデルとデザインの決定について議論するのにチームメンバー全員が使う)のための
　　用語として寄与する。
　　　が、このセクションの主題は、モデルとインプリメンテーションとが互いに有効性を強化するように同期させておくような決
　　定の種類に注目することである。これには、個々の要素への詳細な注意が要求される。この小さなスケールでの注意深い
　　作業は、開発者にパートIIIおよびIVのモデリングのアプローチを適用するためのしっかりとした基礎を与える。

　パートIII：より深い洞察のためのリファクタリング
　　　ビルディングブロックを組み合わせて、実際に使えるモデルを組み立てるという挑戦。奥義のようなデザインの指針へ直
　　接ジャンプするのでなく、このセクションでは発見的なプロセスを強調する。価値のあるモデルは突然に現れるものではな
　　い；それには、ドメインについての深い理解が要求される。この理解は、まず初期のデザインをインプリメントし、それは恐
　　らく未熟なモデルに基づいているかもしれないが、それを再三変形していくこと、これを実際にやってみることから得られる。
　　チームが洞察を獲得するごとに、そのより豊富な知識を反映するようにモデルは変わっていき、コードはリファクタリングさ
　　れて、より深いモデルを反映し、その可能性がアプリケーションに利用可能なものとなる。その後、時において、この玉ねぎ
　　の皮をむきのような作業は、重大な設計変更のラッシュを伴って、はるかに深いモデルに前進する機会をもたらす。
　　　ドメインの探査には本質的に終わりがないが、だからといってそれがランダムなものというわけではない。 パートIII では、
　　　その過程でのさまざまな選択に助言を与えることのできるモデリングの指針、および探索の方向付けを支援する技術に
　　　ついて見ていく。
　パートIV：　戦略的な設計
　　　複雑なシステムや大きな組織において、外部システムまたはレガシー・システムとの相互作用で発生する状況を扱う。
　　このセクションは、システムに適用される三つ組みの法則を考察する：context, distillation, and large-scale structure。戦
　　略的なデザインはチームによって、またはチーム間において決定される。戦略的なデザインは、企業全体に渡るネットワ
　　ークで稼働する大きなシステムあるいはアプリケーションのために、 パートIの到達目標を、大規模スケールで可能にする。
　本の全体にわたり、簡素化され過ぎておもちゃのような問題ではなく、実際のプロジェクトから取り出された現実的な例で、
論点を解説している。

　本の大部分は”パターン”の集まりとして書かれている。読者は、パターン自体について特に気にしなくてもこの本を理解で
きるはずだが、パターンのスタイルおよびフォーマットに興味を持っている人々は補足（appendix）を読むことを勧める。
　補足資料は http://domaindrivendesign.org で見つけることができる。コードの例の追加と議論のコミュニティーがある。

誰がこの本を読まなければならないか

　この本は第一にオブジェクト指向のソフトウェアの開発者のために書かれている。ソフトウェア・プロジェクト・チームのたいて
いのメンバーは、この本のいくつかの部分から利益を得ることができる。この本が最も意味を成すのは、これらのデザインのい
くつかを実際に行うようなプロジェクトに今現在携わっている人々、および、既にこうしたプロジェクトでの深い経験を持っている
人々だろう。
　オブジェクト指向のモデリングについてのいくつかの知識が、この本から利益を得るために必要である。例ではUMLダイアグ
ラムとJavaコードが使ってある。したがって、それらの言語を読む基礎レベルの能力は重要である。が、いずれも詳細をマスタ
ーしておく必要はない。Extreme Programming の知識は、開発プロセスの議論に展望を加えるだろう。が、背景の知識なしでも
理解できるようにはしてある。
　中級のソフトウェア開発者−既にある程度のオブジェクト指向の設計を知っており、１つか２つソフトウェアの設計の本を読ん
でいるであろう読者には、この本はオブジェクトモデリングが実際のソフトウェア・プロジェクト上でどのように使われるかについ
ての展望を提供し、ギャップを埋めるだろう。この本は、中級の開発者が実際的な問題に洗練されたモデリングと設計のスキ
ルを適用することを学ぶのを助けるだろう。

　上級のソフトウェア開発者は、この本の、ドメインに対処するための包括的なフレームワークに興味を持っていると思われる。
デザインへのこの系統的なアプローチは、技術的なリーダーがチームをこうした方向に導く助けになるだろう。さらに、本の全体
にわたって使用される首尾一貫した用語は、上級開発者同士での意思疎通を助けるだろう。
　この本は物語である。最初から最後まで読むことができるし、任意の章の始めからも読むことができる。様々な背景の読者は、
違った順番で読みたいと思うかもしれない。だが私は、どんな読者でも、パートIの前書きと第１章から読み始めることを勧める。
その後では、核心となるのは恐らく章の２，３、９および１４である。ざっと読んで既にトピックをある程度把握した読者は、標題
と太字のテキストとから要点を拾い上げられるはずだ。非常に上級の読者は、パートIとIIをとばしたいかもしれないし、パートIII
とIVに恐らく最も興味を持っているだろう。
　このコアとなる読者に加えて、アナリストおよび比較的テクニカルなプロジェクト・マネージャーもまた、この本を読むことで利
益を得るだろう。アナリストはモデルとデザインの関係に近づくことができ、Agile開発のコンテクストの中でより有効に寄与でき
る。さらに、戦略的なデザインの法則のうちのいくつかを使って、その仕事をより焦点の合ったものに組織化するかもしれない。
　プロジェクト・マネージャーは、より効果的で、ビジネス・エキスパートやユーザにとって意味のあるソフトウェアの設計により焦
点をおいたチームを作ることに関心を置くべきだ。戦略的なデザイン上の決定は、チーム構成や仕事のスタイルと相互に関係
しているが故に、デザイン上の決定は必然的にプロジェクトのリーダーシップを含み、プロジェクトの軌道に大きなインパクトを持
つ。

ドメイン駆動型チーム

　ドメイン駆動型デザインを理解する個々の開発者は価値のある設計技術および展望を獲得するが、チームがドメイン駆動型
デザインアプローチを適用し、かつプロジェクトのディスコースの中心にドメインモデルを移動させるためにともに参加する時、
最も大きな利益が得られる。そうすることによって、チームメンバーは、ソフトウエアに結びついた豊かなコミュニケーションのた
めの言語を共有するだろう。彼らは、アプリケーション開発に影響を与えるモデルと協調した、明瞭なインプリメンテーションを作
り出すだろう。彼らは、異なるチームのデザインワークがどのように関係しているかの地図を共有するだろう。また、組織に最も
特徴的で価値のあるものに、系統的に注意を集中するだろう。
　ドメイン駆動型デザインは、たいていのソフトウェア・プロジェクトが遺産（レガシー）へ化石化し始めるちょうどその時に、変更
の可能性を開き、大きな成果をあげることができる、困難な技術的な挑戦である。

終わりか？
もう終わりか？
これだけで終わりか？
もう気が済んで終わりか？
結局のところ諦めて終わりか？

文字だらけ。読む気が起きん・・・。(’A`)

ぶっちゃけ、Domain-Driven Design は買ったが、各章の序文しか読んでいない。
それだけなら、WEBで公開されているので、買う必要はなかったわけだ。

Code Generation in Microsoft.NET by Kathleen Dollard
http://gendotnet.com/Top%20Level%20Pages/code_gen_in__net.htm

Coder To Developer by Mike Gunderloy
http://www.codertodeveloper.com/

買うべきなのか？買っても読まない気がするが。

http://www.secretgeek.net　で言及されているのでそんな気になっただけなのか。

おお、プ板にも良スレあるやん。
ユースケース駆動に違和感ある漏れ的に、
ドメイン駆動って基本やん、やっぱ押さえなきゃねぇ〜って感じか。
そのうち、レスすると思うんで

デンジャラス・ドライバー・デンリュウってやつか？

26 = 1

この程度の文章で根を上げて
＞難解な用語を撒き散らして弾幕をはりながら
とか言い出すなんて、哀れだな。しかも、馬鹿の一つ覚えでコンサルコンサル言い出してるし。

士農工商＞SE,PG＞＞＞＞２ちゃねらー

閑話休題

ドメイン・エンジニアリングを語る時、やっぱ、
(1)10年位前に流行ってた「エンタープライズ・モデリング」とかの問題点とその後
(2)構造化分析手法〜データ指向分析手法で行われるデータモデリングとの連続性、相違点
ってあたりは避けられないよ〜な気がする。

DDD本は(1)を長年経験した人が著者みたいだけど、
そんな方は(2)についてどーゆー考えを持っているのか、興味津々

＃国内某業界だと、(2)の化石みたいな手法すらろくにこなせない低脳が多すぎる