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

5月から読み始めたので、4ヵ月ぐらいかかったけど、なんとか通読する事ができた。
もっと一気に読んでしまいたいんだけど、なかなか難しい。
この本も他の技術書同様、僕にとてつもない睡魔を襲わせてきたんだけど、一度眠くなったら無理して読んでも頭に入ってこないので、次の日にするかってやっていると、とても時間がかかってしまう。
最近読む技術書は大体眠くなるので、まあ、頭悪いんだろうなと諦めてはいるんだけども。

読む動機

この本はドメイン駆動設計(以下DDD)を語る上で、読んでいないと話にならないという程の有名な本。
僕自身、知り合いのエンジニアの会話中に出てくる「ドメイン」「エンティティ」「バリューオブジェクト」などの言葉が、ずーっともやっとしたままだったのがとっても気持ち悪かったので、どうしても読んでおきたかった本だった。

で、分からないなりにもそういった言葉たちの輪郭が少しはっきりしてきたので、最低限の効果はあったかなと思う。

内容

さすがにこれだけの期間かけて読んでしまうと、最初の頃に読んだことは結構忘れてしまっている。
で、つまるところDDDとは何かというと、

  • 全員が同じ言葉(ユビキタス言語)を話して
  • 全員が同じモデルを共有(イメージ)して
  • そのままの形でシステムに落としこむ

ってことなんだと受け取った。
こうやって書いてしまうと簡単なんだけども、現実問題これを実現するのは相当難しい。
もちろん技術的にも難しいんだが、政治的にも難しいと思う。
ぶっちゃけ出来る気がしない。
ということで、なかなか難しいDDDをなんとか実現する為の手段や方法論があれやこれやと説明されている。

読んで感じたこと

  • コードだけではなく、モデルをリファクタリングしていくという考え方
  • ユビキタス言語で利用している言葉を、そのままクラス名やメソッド名に利用することの大切さ
  • 「ストラテジ」を「ポリシー」として呼び替えると不思議と視野が広がった
  • 「リポジトリ」「エンティティ」「サービス」「バリューオブジェクト」などの整理の仕方
  • 「リポジトリ」またはインフラ層は泥臭い処理が凄そう(その辺りをフレームワークがフォローしてくれるんだろうが)
  • モデルは変化するものという前提、そして変化を歓迎する意識=仕様変更上等
  • 「ソフトウェアの設計は難しく、設計出来ない人をプロジェクトに入れるべきではない」とはっきりと書かれていた点
  • オブジェクト志向プログラミングに対する理解がないと厳しい
  • UMLの知識に必要性を感じた
  • 出てくる題材が最後までイメージするのが難しかった(貨物輸送サービスとか)
  • 「台所」「寝室」「浴室」等の部屋のパターンを例にしたパターンランゲージの重要性
  • ちょっと違うとは思うけど、モデルを「業務知識」と言い換えても良いかも(職場によってだけど)

読んだ後の変化

この本を読んでいる時に既存システムに対する機能追加作業を行なっていたんだけども、コードの書き方が一気に変わった。

具体的にいうと、ファクトリやエンティティ、集約クラスが増えた。
バリューオブジェクトは個人的にとても気に入ったんだけど、既存システムに導入すると一気にクラス数が殖えてしまい、バランスを著しく崩しそうなので諦めた。
リポジトリもバリューオブジェクトやエンティティが中途半端になってしまうと、あまり意味をなさない気がして導入は断念した。
レイヤ化(特にドメイン層の死守)も今後のことを考えると大切だと思ったので、出来るだけそれぞれの層から溢れないように気をつける様に意識はしたが、既に至るところで漏れまくっているシステムだったので、こちらも努力目標程度に留めた。

この辺は、周りの理解だったり環境だったりの関係で、途中からの導入はなかなか難しい。
アーキテクチャを自分が決める立場ではない場合は特に。

そして言葉や名前の付け方を今まで以上に気にするようになった。
ドメインエキスパートとはいかなかったが、デザイナーやディレクターの人たちとのコミュニケーションの量を増やして、共通の言葉やイメージを持てる様に努力するようになった。
これはこれで結構なコストがかかるんだけど、実際にやってみるとメンバーには好評のようだ。
これらについては、DDDの影響というよりもアジャイル関連の影響だな、けど驚くほどリンクしている気がする。

完全な新規開発のシステム案件はなかなか無いので、こんな感じで既存システムの中で出来るところからコツコツとって感じになる。
それが現実解だと思うし、ゆっくりでも改善されているのであれば、それで良いかなと思っている。
システムを変更するのも大変だが、人間はもっと変えるのは大変だ。

DDDを理解している人だけでチームを作れるプロジェクトなんてあるんだろうか。
どこかでこの本は新人エンジニア必読とか見かけた気がするけど、設計の実務経験がないと、ピンとこない気がするんだけど、どうだろうか。

まとめ

非常に抽象的な話をしている反面、生々しい体験談や結論なんかもありなんとも不思議な本だった。
「そうか、頭の良い人達は設計する時にこんなことを考えているのか」
と思うと面白いと感じる反面、自分の何も考えてなさに愕然とした。
ま、これは大体本を読むと感じることなので、良い加減慣れてきたけど。

まあ、DDDを自分で実践するのは至難の業だと思う。
そもそもかなり環境を選ぶ気がするし、周りの理解が必要だ。
そして、周りを説得するだけ自分が理解できてないというのも大きい。
やるべきことは山積みだな。

あと読んだ直後の感想としてはアレだが、DDDが全てではないと感じている。
案件やプロジェクトの状況によって、しっくりくる設計手法って他にある気がする。
けどDDDは、至るところで目にするので、教養として知っておいて損はないと思うし、実際知っていると引き出しが増えてきっと良い影響を与えてくれるはず。
少なくとも自分にとってはそうだったかな。 個人的には時間はかかったけど、読んで良かったなと心から思った。

また設計する時にパラパラとページをめくって、この本に書かれているアイデアを利用出来たらなと思う。
きっとその時々で新しい発見があるだろう、それが今から楽しみだ。