設計手法？なにそれおいしいの？雰囲気で設計していた自分にドメイン駆動設計がどう役に立ったのか

おれたちは雰囲気で設計をしている

• 一応アプリケーションを一から作ることはできるけれども、疎結合とか単一責任の原則とかの戦術レベルの知識やいくらかの経験を頼りに雰囲気で設計をしていた。
• 設計手法について用語だけなんとなく聞いたことはあるけど、一応設計はできているつもりだしあんなのはスーツのおもちゃだろうくらいしか思っていなかった。

ドメイン駆動設計に出会う

• Yuki Anzai さんのドメイン駆動設計についての発表資料をブログにまとめたものでドメイン駆動設計に出会った。
• 資料がわかりやすく、なんとなく経験則として感じていたことが言語化されたりよりよい方法を提示されたりした気がして楽しかった。
• ドメイン駆動設計についてちゃんと調べなければいけないと思いエリック・エヴァンスのドメイン駆動設計を読んだ。

ドメイン駆動設計とは

• 入門として先のブログがわかりやすい。この記事では解説はしない。
  • この記事書くのにブログ見ていたら Anzai さんがドメイン駆動設計の入門本を出していた。買って読んでみたけどこれもわかりやすくて入門によさそう。
• エリック・エヴァンスのドメイン駆動設計は分厚いけどガッツで読むといい。冗長でわかりづらいようなレビューがあるけど結構ユーモアもあって楽しく読めた。
  • Qiita とかでも解説記事がいっぱいあるので先にそっちを読んだり平行して読んでもいいかもしれない。
• 実践ドメイン駆動設計はエヴァンス本とかぶっているところも多くて順番に読んだら飽きてしまって全部読めていない。ユーモアセンスも個人的に合わなくて辛かった。
  • こんな記事を書いて他人に紹介しておいて自分は知りませんっていうのはやっぱりない気がしてきたのであとでちゃんと読む。

ドメイン駆動設計はどう役に立つか

おじさんだって悩んでいる

問題

• 設計がうまくいかない時、自分が頭が悪いからうまくできないんだろうなーとか惨めな気持ちになることがよくあった。

解決

• ドメイン駆動設計ではソフトウェアが取り扱う問題が複雑である場合はソフトウェア自身も当然複雑になるということを言っている。
  • 複雑ではない問題を解決したい場合はそもそもソフトウェアを作る必要もあまりないので（手習いの Hello World なんかを除いて）ソフトウェアは本質的に複雑なものである。
  • ドメイン駆動設計ではここから続けていかにその複雑さをコントロールするかという流れになる。
  • ちなみにドメイン駆動設計の"ドメイン"とは"ソフトウェアが取り扱う問題領域"のこと。
• ベテランエンジニアのエリックおじさんも最初から完璧な設計ができるわけではなく、ドメインに詳しいひとと相談をしたり実装したりしながら分析してより良い設計へとリファクタリングを繰り返すという地道なことをしている。
• 「ソフトウェア開発は複雑だ」ということを誰かに言ってもらえることはとても救いになった。自分だけが苦しんでいるわけではなくみんなが苦しいのだということは一見悲観主義的だが、苦しいのを当然として立ち向かう覚悟を持つことができるようになった。大げさかもしれないがブッダが「一切皆苦」と説いて苦難についてよく分析しコントロールするすべを教えたことにも似ているように感じる。

修正は手戻りか

問題

• 仕様決めて設計して実装した後にやっぱりここはこうした方がいいということで修正をすることがある。
• 動かしてみて初めて気がつくことはあると思うので自分的には修正は問題ない。
• が、最初からそっちの仕様出せよとかモチベーション下げたり仕様決定者と対立したりする人はいるので、このしょうがないよねーという感覚をどうにか共有できたらいいなと思う。

解決

• ドメイン駆動設計では最初からドメインについて十分に理解できていないという態度を取り、不十分な理解でもモデリングをし実装をしながら分析を行うことでドメインについての理解を深めてリファクタリングをしていくというプロセスを経て完璧なモデルに近づけていくという方法を取る。
• 全知全能ではない以上すべての要件を最初から把握しておくことは不可能である。実装して初めて新しい要件に気がついたときには、手戻りではなくドメインへの理解が深まったのだととらえてポジティブに修正を進めていけるようになりたい。なるといいな。

おまけ

• それでもやっぱり一旦実装しないとわからないというのは自分の能力に問題があるのかなーとか思っていたが、事前に設計をしっかりやるタイプのユースケース駆動開発実践ガイドを読んでみて、設計しっかりやる人もユースケースモデルつくって、ロバストネス分析つくって、シーケンス図つくって、とコードではないが何らかの形での実装を実際に何度もやることで設計を固めているのだということがわかって安心した。
• 設計を一発で完璧にやるというのはやっぱり夢物語だ。それでなければサービス稼働率を 100% にしたりバグ発生率 0% をめざすようなコストに見合わない過度な目標設定だ。

良い設計とは

問題

• 自分で書いているコードやレビューしているコードでなんとなく筋が悪い設計な気がするがうまく言語化できないことがある。
  • 「これは早すぎる最適化ですよ」とかなんとなくの指摘はできるがどうして駄目なのかちゃんと説明できない。

解決

• 良い設計とは何かという軸がなかったのが問題。
• ドメイン駆動設計のテクニックは複雑さを解きほぐして小さくしうまくコントロールすることを目的としている。
  • エヴァンス本のサブタイトルは「ソフトウェアの核心にある複雑さに立ち向かう」。
• 設計の良し悪しとは複雑さをうまくコントロールできているかどうかという基準を持てるようになった。
  • 例えば早すぎる最適化については、ドメインについて理解が不十分な段階で過度に構造化をすることは後に発生するリファクタリングの妨げとなるので筋が悪い場合があると言えるようになった。

おわりに

• ドメイン駆動設計はよく紹介されている実装テクニックも役に立つが根本の考え方もとても強力で役に立つものだと思っている。
• ぜんぜん知らない人にはテクニック部分の用語解説とかから入るのは厳しいと感じるので、ぜんぜん知らない人向けに詳細に触れずにふわっとどういう方面に役に立つのかを紹介されているものがあってもいいと思いこの記事を書いて見た。