Zac Fukuda

Eric Evans『Domain Driven Design』

随筆, 日記
  • 本
  • 読書
  • ソフトウェア開発
  • プログラミング

宣教活動

アメリカ人は宣教活動が好きだ。そして、オレは宣教活動が嫌いだ。するのもされるのも。

英語版の Domain Driven Design (以下、DDD) はインデックスまで517ページ。「サルでもわかる」本が好きな日本人にとっては中々の重厚本だ。しかし、その重厚本も、宣教活動目的のため、内容を過剰に盛られている現実を理解すれば、“人間ならわかる”本として捉えられる。

Domain driven、test driven、event driven。我こそは次なるソフトウェア開発のパイオニアになろうと造られる言葉たち。ふざけたことに Domain driven の中に model driven まで登場する。これら造語は一旦忘れ、メッセージに目を向けるとDDDは遥かに理解しやすくなる。

DDDのメッセージは明瞭だ。ソフトウェアはビジネスを投影しなければならない。ただ、要件だけ聞いて、要件を満たすだけ、動くだけののソフトウェア開発はするなということ。当たり前と言えば当たり前の話だが、実行するのは極めて困難だ。

落とし穴

「ソフトウェアはビジネスを投影しなければならない」を実現する方法として昇華された手法が DDD である。個人的な見解だが、日々「どうずればもっと変更・修正に柔軟、別開発者が入ってもすぐ理解できるコードを書けるか」を考え仕事に取り組めば、DDDの唱える理想論からそう遠くはない実装になると思っている。

だが、DDD をチームへ導入することは、一つの明確な基準を定めることであり、集団開発の統一化・効率化を図る上で、非常に有効であることは間違いない。Entity のことを我流で genus と読んでいたら、他開発者からは 「Genus?」となるわけだ。(Genus を ubiquitus language として共有化することもできるが。)

DDDのスタート地点は domain知識を得ること。domainを知った後、デザイン、実装とフェーズを移行するのがDDD的な最善策と言える。

だが、悲しくもDDDの落とし穴はここにある。

おそらく、DDDを完璧に達成しようとするチーム・プロジェクトは、何も造らずに失敗に終わるだろう。プロトタイプすら作ろうとしないチームのコミュニケーションが頭に浮かぶ。

以前、納期が二ヶ月に迫ったECサイト開発プロジェクトに途中参画したことがある。ECサイトと言っても従来のECサイトを作るのにエンジニアは必要ない。詳細は省くが、ただのオンライン通信販売サイトではない、新しいECサイトを作ることがプロジェクトの内容であった。

その時エンジニアチームは、画面遷移図、DBスキーム、造らなければならないモデルの種類などを議論していた。納期に反して一行もコーディングをしていなかった。その日に一行もコーディングしていなかったわけではない。プロジェクトがスタートしてから一行もコーディングしていなかったのである。

呆れたオレはチームメンバーを無視してコーディングを始め、その日のうちに開発サーバーを立ち上げ、その日から毎日開発サーバーにコードをプッシュしていくことを告げた。

DDDという観点から当時のオレの行動を採点すれば、100点満点で10〜20点ぐらいだろう。せいぜい採れたのは努力点ぐらいだ。納期の時点でアプリは完成しなかったが、完成の目処が立っており、(おれと同じように議論は置いて、開発に専念しくれた他開発者との協力も相まって、) 大元の依頼主からは及第点をもらえることができた。

DDDの主コンテンツはあくまで「ドメイン駆動」。しかし、時折著者が同書で述べている通り、実装を通すること、つまり手を動かしてプログラミングをすることでより問題が鮮明になり、より深いドメイン知識を得られる。この事実が前提のDDDだ。

DDDの最終章に以下の一文がある。

But though improved tools will be valuable, we mustn’t get distracted by them and lose sight of the core fact that creating good software is learning and thinking activity. Modeling requires imagination and self-discipline. Tools that help us think or avoid distraction are good. Efforts to automate what must be the product of thought are naive and counterproductive.

ここで著者は、DDDはあくまでツールの一つであると暗示的に警鐘を鳴らしているのかもしれない。

口より頭より手を動かそう。今日もオレは。

一覧へ戻る