ドメイン駆動設計の原典。 原典だけあって一度は目を通しておきたいし、じっくり読み込む機会を設けたいと思う一方、本書と同じ言葉で語るには訓練が必要である（たとえば「モデル」という言葉）。 理解はしたいが、おすすめはしづらい。

モデルの作成について参考になることは書いてあるけど、読みづらさが勝った。 文章の流れがわかりづらかったり、冗長で不要な内容であったり、例もあるが説明不足だったり、日本語としてもわかりづらかったりで、原著にも翻訳にもどちらともに問題があると感じた。 書いてあることは★４～５だが、読みづらさは★１～２なのでトータルで評価は★３とした。。

原書が2003年なので、2021年現在からみると、古典中の古典ですね。当時流行っていたXPとかオブジェクト指向開発などの文脈を理解しつつ、難解な文章を汲み取る根気が必要とされる本だと思います。自分は一応最後まで目を通したものの、早々にちゃんと理解することを諦めました。 要は、業務に詳しいけど技術はそれほどでもない人と、技術は詳しいけど業務はそれほどでもない人がいる。つまり、両方に詳しい人なんてのはいないので、用語を統一して（ユビキタス言語）、システムに必要な要素を抽出して（蒸留して）、ドキュメンテーションして（モデル化して）、ステークホルダー間で会話していこうぜっていう話なんだと思います。そんなこと分かってるわって怒られそうですね。その課題に立ち向かうための話が種々書かれているので、もしかしたら現代でも参考になる点もあったかも知れません。 Web系企業っていうのは、自社のビジネス＝業務を自分たちで開発するので問題が起きにくいのかなと。あるいは、自社開発っていうのもその流れですよね。 自分の場合は、金融系ITスペシャリストみたいな感じなので、対象ドメインの知識と、IT知識とそれぞれの流行をキャッチアップしていかないといけません。まあーそんなの分かってるけど、両方分かる人は希少価値があることだし、改めて意識していこうかなと思いました。

名著と言われている。前半だけでも結構楽しめた。 ただ、説明がわかりにくかったりして後半は飽きてしまった。 ドメイン駆動設計 モデリング実装ガイドを事前に読んでいたからどうにか読み終えることができた、という感じ。とはいえ、軽量だろうと本格だろうと、DDDに入ろうとしたら登竜門になるので必読書なのかもしれない。

DDDの文脈で「エンティティ」「バリューオブジェクト」「サービス」「集約」といったものが何を指すのか理解できました。実践ドメイン駆動開発は現在精読中ですが、こちらの本を先に読む方が良いと思います。 「境界づけられたコンテキスト」がマイクロサービスと相性が良いと言いますが、マイクロサービスに関する和書は数少ないためその意味でもこの本は重要だと思いました。

「ドメイン駆動設計」なるものは何なのか。 例えばテスト駆動開発であれば、テストを実装しそこからレッド→グリーン→リファクタリングと進んでいく。 ではドメイン駆動設計はドメインが起点かというと、むしろリファクタリングしながらドメインを浮き彫りしていく彫刻のようなアプローチが望ましいようだ。 (第八章ブレイクスルーのあたりにくわしい) 一度通読しただけで完全に理解できるような代物ではないが、いかにしてコード、そして設計にドメインを注入していくのかというコア部分は必読。 第4部、戦略的設計は内容的にも入り組んでおりやや難解に感じた。再読が必要だ。 重厚で、かつ内容を噛み砕きながら読む必要があるため相応の覚悟は必要。

初見だと新しい概念が大量に出てきて、理解できないままどんどん話が進んでいきます。 それもあり放置していた本ではあったのですが、DDDで設計されたプロジェクトに入った機に再読。 実際に触りながら読むと、前より理解しながら読み進めることができました。 時代背景も今と違うため、素直に全てを受け止めるのではなくどんな理由があってなにを解決するために生まれたものかを理解するのが大事かと思われます。 特にアーキテクチャとしての戦術的DDDをDDDの全てとして受け止めてる人も多く、その辺りが曖昧になると本質を見失ってしまいそうです。 １回読んだだけで理解できる本ではないため、実践を繰り返しながらより深い理解を進めていきたいと思います。

重厚な本で、読みきるのに結構時間がかかる。 筆者が開発を行っている際に現れた課題を題材に、どのように解決に向かっていくのかを、参考にした他の著書やパターンなどを引用しつつ、DDDの概念に当てはめて説明していく形になっている。 何よりこの本を読んだことで、複雑なシステムに対するモチベーションが高まった。

まず翻訳が酷く、ほぼ直訳で、これがとても本書を読みにくいものにしている。 ドメインを資産にしていくという考えはとても重要なのだけど、内容がかなり観念的で理解が難しい。 ドメインのライフサイクルモデルとして第六章にあがっている、ファクトリ、リポジトリの概念、そこだけは直感的に理解可能だった。 ２００３年発行の古い古典だが、そのエッセンスは現代でも不変だと思う。ただし、伝わらないと意味がない。 英語版を一冊購入して、1年後ぐらいに読み返してみる。

# 書評☆2 エリック・エヴァンスのドメイン駆動設計 | DDDの基礎理論 ## 概要 ドメイン駆動設計 (Domain Driven Design: DDD) とよばれるソフトウェアの設計手法の提唱者により，基礎理論が解説されている。 業務領域に合わせて設計することで，大規模で複雑な設計もうまく対応できるらしい。 書籍内では，具体的な事例を上げながらこれはこうというような感じで説明されていた。具体例を上げてそこから一般的なことをいうという帰納的な論理展開がされていて，読んでいる側としてはかなりわかりにくかった。 小難しい内容が小難しく書かれており，わかりにくかった。 そもそもドメインとは何か？という根本的なところがわかっていなかったのだが，結局ドメインとは何かはどこにも書いていなかった。ある程度わかっている人向けに書かれているようだ。 図解もたくさんあるのだが，クラス図みたいなものでモデル化されているので，DDDの基本的な考え方がわからないので意味不明だった。 ## 参考 > ### p. iv: 日本語版への序文 > 根本的には、DDDを駆動している原則は次の3つだけです。 > * コアドメインに集中すること。 > * ドメインの実践者とソフトウェアの実践者による創造的な共同作業を通じて、モデルを探求すること。 > * 明示的な境界づけられたコンテキストの内部で、ユビキタス言語を語ること。 既にこの原則の部分で意味のわからない用語が大量に出てきた。本文中で解説があって理解できるかと思ったが，結局できなかった。 ## 結論 はっきりいって自分には全く理解できなかった。おそらく，大規模で複雑な設計時には役に立つ考え方なのだろう。 大規模なソフトウェア開発に従事し，その設計を担当するような，少なくとも中上級者向けの内容だと感じた。 DDDについて知りたいなら，もっと簡単に書かれた他の本をあたったほうが良いだろう。 パーマリンク: https://senooken.jp/blog/2018/07/17/

本書は「ドメイン駆動設計」という、ソフトウェア・システムのモデリングおよび設計手法について説明したものである。 ドメイン駆動設計は「ドメイン知識駆動設計」とよぶ方がわかりやすいと思う。 これは、業務のモデリングおよびシステムの設計に、クライアントであるドメインエキスパートと共通の語彙を使ってモデリングから設計の詳細までを行おうという手法である。 これによりモデルと実装が乖離することがなく、ドメインエキスパートおよびソフトウェア・エンジニアがつねに対話しながら、彼らの知見を活かしてモデルとシステムを改良し続けられるとしている。これが本書のメインテーマである。 そして、モデルをシンプルにするために、値オブジェクトやimmutableなオブジェクトを使うことを推奨し、コンポーネントの疎結合化、レイヤー化の導入を提案する。これが本書のサブテーマである。 ただし、既存のシステムが存在する場合などでは、全て理想的に行くとは限らないので、その場合の解決・妥協方法について本書の後半で述べられている。 実際にシステムを構築した人でないと後半は漠然としていてわかりにくいが、前半は例を用いて明確に書かれており、それだけでも本書を読む価値はあると思ったので★4つとする。

京都で読書会をやってました。 序盤のDDDの基礎的な部分も面白いが、後半の実践するための様々な手引き部分が業務とリンクしてとても読み応えがある。 ただ、モデリングを始めようとして手に取ると、モデリング手法については一切触れていないので不完全燃焼になるかも。 この本はあくまでもモデリングができる前提で、モデルを利用した開発の仕方を説明している本なので注意が必要。

howtoより啓蒙本かなぁ 経験してないと腑に落ちない気がする ユースケースドリブンとは併用できなそう 強いアーキテクチャ制約を課すとDDDの良さは出なそう アジャイルというかイテレーション開発が受け入れられるか、お客さんのスキルレベルと参画度合いにDDD実現のキモと言えそう

難しい言い回しもあり、理解出来ない点もあったが、 共感でき、役に立つ部分も結構あり。 またしぱらくたって、読みなおせば違った収穫がありそう？

ある程度以上の規模を持つシステムを構築する際には、一通り目を通しておくべき書籍です。 ESBによるシステム統合のベストプラクティス(コンテキスト境界)と同じ話が出てきてびっくりしました。合併によるシステム統合の際などにも、参考になるアイデアがいろいろ詰まってます。

面白い。久しぶりにソフトウェア工学の本を面白いと思った。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）

---2011/7/15--- とりあえず１回読みました。 ズバリ今の私には非常に有益な本でした。 オブジェクト指向の開発経験が乏しい私にはピンと来ず、すんなり理解できない箇所もあったので、この先繰り返し読もうと思います。 筆者が関わったプロジェクトの様々な失敗の様子も記載されているのもよいです。 それらが自分の会社の状況と非常に似通っており、ちょっと気が重くなったりもします。 ドメイン駆動開発、モデル駆動開発、オブジェクト指向での開発をしていない方にも役立つ内容がたくさんあると思います。 記載されている内容を自分のプロジェクトと組織に合わせ、実践できるようになりたいです。