エリック・エヴァンスのドメイン駆動設計: ソフトウェアの核心にある複雑さに立ち向かう
- 翔泳社 (2011年4月1日発売)
本棚登録 : 949人
感想 : 34件
- Amazon.co.jp ・本 (538ページ)
- / ISBN・EAN: 9784798121963
感想・レビュー・書評
-
名著と言われている。前半だけでも結構楽しめた。
ただ、説明がわかりにくかったりして後半は飽きてしまった。
ドメイン駆動設計 モデリング実装ガイドを事前に読んでいたからどうにか読み終えることができた、という感じ。とはいえ、軽量だろうと本格だろうと、DDDに入ろうとしたら登竜門になるので必読書なのかもしれない。
2
詳細をみるコメント0件をすべて表示 -
まず翻訳が酷く、ほぼ直訳で、これがとても本書を読みにくいものにしている。
ドメインを資産にしていくという考えはとても重要なのだけど、内容がかなり観念的で理解が難しい。
ドメインのライフサイクルモデルとして第六章にあがっている、ファクトリ、リポジトリの概念、そこだけは直感的に理解可能だった。
２００３年発行の古い古典だが、そのエッセンスは現代でも不変だと思う。ただし、伝わらないと意味がない。
英語版を一冊購入して、1年後ぐらいに読み返してみる。
2
-
原書が2003年なので、2021年現在からみると、古典中の古典ですね。当時流行っていたXPとかオブジェクト指向開発などの文脈を理解しつつ、難解な文章を汲み取る根気が必要とされる本だと思います。自分は一応最後まで目を通したものの、早々にちゃんと理解することを諦めました。
要は、業務に詳しいけど技術はそれほどでもない人と、技術は詳しいけど業務はそれほどでもない人がいる。つまり、両方に詳しい人なんてのはいないので、用語を統一して（ユビキタス言語）、システムに必要な要素を抽出して（蒸留して）、ドキュメンテーションして（モデル化して）、ステークホルダー間で会話していこうぜっていう話なんだと思います。そんなこと分かってるわって怒られそうですね。その課題に立ち向かうための話が種々書かれているので、もしかしたら現代でも参考になる点もあったかも知れません。
Web系企業っていうのは、自社のビジネス＝業務を自分たちで開発するので問題が起きにくいのかなと。あるいは、自社開発っていうのもその流れですよね。
自分の場合は、金融系ITスペシャリストみたいな感じなので、対象ドメインの知識と、IT知識とそれぞれの流行をキャッチアップしていかないといけません。まあーそんなの分かってるけど、両方分かる人は希少価値があることだし、改めて意識していこうかなと思いました。
1
-
「ドメイン駆動設計」なるものは何なのか。
例えばテスト駆動開発であれば、テストを実装しそこからレッド→グリーン→リファクタリングと進んでいく。
ではドメイン駆動設計はドメインが起点かというと、むしろリファクタリングしながらドメインを浮き彫りしていく彫刻のようなアプローチが望ましいようだ。
(第八章ブレイクスルーのあたりにくわしい)
一度通読しただけで完全に理解できるような代物ではないが、いかにしてコード、そして設計にドメインを注入していくのかというコア部分は必読。
第4部、戦略的設計は内容的にも入り組んでおりやや難解に感じた。再読が必要だ。
重厚で、かつ内容を噛み砕きながら読む必要があるため相応の覚悟は必要。
1
-
重厚な本で、読みきるのに結構時間がかかる。
筆者が開発を行っている際に現れた課題を題材に、どのように解決に向かっていくのかを、参考にした他の著書やパターンなどを引用しつつ、DDDの概念に当てはめて説明していく形になっている。
何よりこの本を読んだことで、複雑なシステムに対するモチベーションが高まった。
1
-
# 書評☆2 エリック・エヴァンスのドメイン駆動設計 | DDDの基礎理論
## 概要
ドメイン駆動設計 (Domain Driven Design: DDD) とよばれるソフトウェアの設計手法の提唱者により，基礎理論が解説されている。
業務領域に合わせて設計することで，大規模で複雑な設計もうまく対応できるらしい。
書籍内では，具体的な事例を上げながらこれはこうというような感じで説明されていた。具体例を上げてそこから一般的なことをいうという帰納的な論理展開がされていて，読んでいる側としてはかなりわかりにくかった。
小難しい内容が小難しく書かれており，わかりにくかった。
そもそもドメインとは何か？という根本的なところがわかっていなかったのだが，結局ドメインとは何かはどこにも書いていなかった。ある程度わかっている人向けに書かれているようだ。
図解もたくさんあるのだが，クラス図みたいなものでモデル化されているので，DDDの基本的な考え方がわからないので意味不明だった。
## 参考
> ### p. iv: 日本語版への序文
> 根本的には、DDDを駆動している原則は次の3つだけです。
> * コアドメインに集中すること。
> * ドメインの実践者とソフトウェアの実践者による創造的な共同作業を通じて、モデルを探求すること。
> * 明示的な境界づけられたコンテキストの内部で、ユビキタス言語を語ること。
既にこの原則の部分で意味のわからない用語が大量に出てきた。本文中で解説があって理解できるかと思ったが，結局できなかった。
## 結論
はっきりいって自分には全く理解できなかった。おそらく，大規模で複雑な設計時には役に立つ考え方なのだろう。
大規模なソフトウェア開発に従事し，その設計を担当するような，少なくとも中上級者向けの内容だと感じた。
DDDについて知りたいなら，もっと簡単に書かれた他の本をあたったほうが良いだろう。
パーマリンク: https://senooken.jp/blog/2018/07/17/
1
-
ある程度以上の規模を持つシステムを構築する際には、一通り目を通しておくべき書籍です。
ESBによるシステム統合のベストプラクティス(コンテキスト境界)と同じ話が出てきてびっくりしました。合併によるシステム統合の際などにも、参考になるアイデアがいろいろ詰まってます。
1
-
色々と学んだことも多い一方で抽象的な概念も多く、具体的に自分のものにするためには実践するしかないんだろうなぁと
エンジニアとしてもっと経験を積んでから改めて読み直したい
0
-
DDDの文脈で「エンティティ」「バリューオブジェクト」「サービス」「集約」といったものが何を指すのか理解できました。実践ドメイン駆動開発は現在精読中ですが、こちらの本を先に読む方が良いと思います。
「境界づけられたコンテキスト」がマイクロサービスと相性が良いと言いますが、マイクロサービスに関する和書は数少ないためその意味でもこの本は重要だと思いました。
0
-
初見だと新しい概念が大量に出てきて、理解できないままどんどん話が進んでいきます。
それもあり放置していた本ではあったのですが、DDDで設計されたプロジェクトに入った機に再読。
実際に触りながら読むと、前より理解しながら読み進めることができました。
時代背景も今と違うため、素直に全てを受け止めるのではなくどんな理由があってなにを解決するために生まれたものかを理解するのが大事かと思われます。
特にアーキテクチャとしての戦術的DDDをDDDの全てとして受け止めてる人も多く、その辺りが曖昧になると本質を見失ってしまいそうです。
１回読んだだけで理解できる本ではないため、実践を繰り返しながらより深い理解を進めていきたいと思います。
0
-
本書は「ドメイン駆動設計」という、ソフトウェア・システムのモデリングおよび設計手法について説明したものである。
ドメイン駆動設計は「ドメイン知識駆動設計」とよぶ方がわかりやすいと思う。
これは、業務のモデリングおよびシステムの設計に、クライアントであるドメインエキスパートと共通の語彙を使ってモデリングから設計の詳細までを行おうという手法である。
これによりモデルと実装が乖離することがなく、ドメインエキスパートおよびソフトウェア・エンジニアがつねに対話しながら、彼らの知見を活かしてモデルとシステムを改良し続けられるとしている。これが本書のメインテーマである。
そして、モデルをシンプルにするために、値オブジェクトやimmutableなオブジェクトを使うことを推奨し、コンポーネントの疎結合化、レイヤー化の導入を提案する。これが本書のサブテーマである。
ただし、既存のシステムが存在する場合などでは、全て理想的に行くとは限らないので、その場合の解決・妥協方法について本書の後半で述べられている。
実際にシステムを構築した人でないと後半は漠然としていてわかりにくいが、前半は例を用いて明確に書かれており、それだけでも本書を読む価値はあると思ったので★4つとする。
0
-
DDDに関する本として最初に読むべき本とのこと。
自分ではない誰かの業務領域にむけた大規模システムを設計するときにどうあるべきか、ということが書いてある。考え方はどの業界においても一緒だと思うので、概念は知っておきたい。
ドメインを深く理解し、いかにそれを邪魔しないよう設計するかという話。副次的な効果としては物流業界に詳しくなれる。
0
和智右桂の作品
