エリック・エヴァンスのドメイン駆動設計を読んだ - イノたまごラボ・あのぶるの「こんなの作ったよ！」

公約通り読みました、エリック本。雑多なんですけど感想まとめ。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

作者:エリック・エヴァンス
発売日: 2011/04/09
メディア: 大型本

現時点でのDDDの理解としては、「現実のビジネスに寄り添うために、ドメインエキスパートとよく話し合って設計しようね」であり、いわゆる「コード読んだらわかるでしょ」を案件関係者全員(非開発メンバー含め！)に対して実現することを半ば本気で目指すための開発手法とかものの考え方である、という感じ。

アジャイルとかエクストリームプログラミングが割とキーワードとして頻出だったんですが、(当たり前の話とは言え)ビジネスメンバーがそのドメインに関してのエキスパートであることを大前提としてるのはアジャイル開発と共通してるのかなぁってちょっと思いました*1。「すごいな」って思うソフトウェアエンジニアの人、みんなちゃんとお客さんのことよく見てるし。
新規サービスの開発とか、ゲームの開発とか、案件によってはチームでドメイン知識自体を作り上げながらの開発になるので、そういうチームだと本当に実装をドメインに追従させるスピードを保つって大切だし大変なんだよなーって思います。

軽量DDDというか、モデル駆動設計でのデザインパターンを手によく馴染ませるというのは確かに大事だなぁというか、語彙として自由に使えるようになるまではちょっと難しいかもというか難しかったので、この間読んだドメイン駆動設計入門ボトムアップでわかる！ドメイン駆動設計の基本の凄いところってそういうことなのかなぁと。本格的なDDD本読む前に読むの、確かにお勧めです。それからその辺の具体的なコードの書き方に言及しているあたりって「(ドメインをクリーンに保つために)リファクタリングしやすいコードの書き方」の話なので、そこだけマネしてもある程度有効ってのは確かにそうなのかなーとは思いました。私もまだ自由に使いこなすところまで至ってないのですが、確かに良さそうという実感は感じ始めています。
ただ、たぶんデザインパターンのところはもしかしたら「現状のベストプラクティスはこれ」という話であって実はあんまりDDDの本質(？)ではないというか、「この形を守ったらDDDである」ということではないのかなーと思っていて、おそらくこの本で言及されていたデザインパターンじゃなくても、体系立てた設計でドメイン知識をコードに最大限詰め込むことが出来ればおそらくDDDとしてはアリなんじゃないかという理解をしました。
……というところまで行ってこの記事を読み返してハッとするところまでがワンセットでした。(チートシート印刷して自宅デスクに貼ってあります🙌) qiita.com

で、前述のとおり何のためにDDDを使うかって「現実のビジネスに寄り添うため」で、かつドメインエキスパートと積極的にコミュニケーションしないのもアジャイル開発を前提とするならわりとあり得ない気がするので、DDD不要論に対しては「アジャイルな開発をやるつもりがない」か「当たり前過ぎて手法として括る必要を感じていない」か「私が何か致命的な勘違いをしている」かのどれかなんじゃないかなぁって思っています。~~たぶん最有力候補は一番最後~~
実際、無意識的にやってる人も一定数居ると思う。アジャイルであるとはどういうことか的な議論と同じ感じで形だけ整えればいいってものではないし、この考え方にDDDって名前を付けたっていうことに意義のひとつがあるんだろうな、とか。

そして「どういう役割があって何をしたいのか」をクリアにするのが目的と考えると、読みやすい文章の書き方とかデザイン分野の情報設計みたいなところに通じるものがあるはずだなって思ったのでその辺の知識も仕入れたくなってきました。

ということで、最後にエリック本を読んで読みたくなった本のまとめ。部屋の次読む本ゾーンに既に3冊くらい積んでるので正直消化スピードが追いつきません。