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