DDDになぜ失敗するのか - 歴史から見つめ直すDDD
日本においてDDDは2020年前後から今まで以上に注目を集め始め、多くの会社で実践されるようになりました。
そのためか、DDDを最近生まれたモダンな設計手法と勘違いしている人もチラホラ見てきました。
しかしエヴァンスがDDDの本を出したのは2003年です。
つまり20年間流行しなかったものが、突然注目され始めたともいえます。
そんなDDDは、20年間どのような経緯を歩んできたのか。
DDDを取り巻く時系列をもとに考察していきます。
DDDを取り巻く時系列
PoEAAからDDD
DDDを語る上で触れないわけにはいかないのが、『エンタープライズ アプリケーションアーキテクチャパターン(PoEAA)』です。
PoEAAはアプリケーション開発における設計パターンをまとめた本であり、DDDで提唱されるリポジトリ、ドメインモデルなどの概念はここに記載されています。
現代人がエヴァンス本を読んで理解できないのは詳しい具体例もなく突然新しい概念が出てきくる面が大きいと感じます。
一方でこの本が出たタイミングでは、こうしたパターンが共通認識としてあったということです。
その上で「ドメインを実装に落とし込むのに最適なパターンの組み合わせはこれだったぜ！」って言っていたのがあの本だったわけですね。
エヴァンスがDDDの執筆時に突然リポジトリやドメインモデルという概念を生み出したわけではないということです。
Webフレームワークなき時代
DDDが書かれた時代は、Webフレームワークがほとんど使われていなかったころです。
主要なWebフレームワークがリリースされた年を見ても、DDDが出版された後です。
つまりDDDが出版された頃はフレームワークなしで毎回1からシステムを開発したり、企業ごとにフレームワーク的なものを作るのが一般的だったのではないでしょうか。
こうした時代背景だからこそPoEAAという設計パターンをまとめた本が出版され、注目を集めました。
そこから、様々な人が「このパターンの組み合わせこそ最強！」と名乗りを上げ、本を出版したりフレームワークを作ったりしてきたのではないでしょうか。
たとえばRailsで採用されてるActiveRecordもPoEAAに記載されてるパターンの１つです。
ゼロ年代のDDD
さて、DDDが出版されてすぐに日本で普及したかというとそんなことはなく、翻訳版は約10年後の2011年に出版されます。
「DDD難民に捧げる Domain-Driven Designのエッセンス」には、2007年は以下のような状況だったと書かれています。
しかし、日本では翻訳書がいまだに出版されていないこともあり、本書の出版から3年近く経った今でも、まだまだ一部の通の人たちにしか広まっていないように筆者には思われます。また、原書を読まれた方の中からも「本が分厚すぎて読みきれない・・・」という嘆きの声も聞かれます（DDD難民という言葉もあるそうです）。
DDD難民に捧げる Domain-Driven Designのエッセンス
また日本に限らず世界的に見ても芳しい状況とは言えなさそうです。
たとえば
MDAツールSculptorのように、DDDを積極的に採用したツールやフレームワークも登場しつつあります
DDD難民に捧げる Domain-Driven Designのエッセンス
とありますが、ScluptorのようにDDDを積極的に採用したツールやフレームワークが大きなシェアを獲得できなかったことは一つの事実です。
Googleで働いているRohit氏は2010年ごろの状況について以下のように記述しています。
Eric Evans が独創的な著書 Domain Driven Design ( DDD ) で作成したドメイン駆動設計の理論は、2003 年 8 月 30 日に出版されました。 ... 現時点では、ほとんどのソフトウェア エンジニアはドメイン駆動設計の戦術的および戦略的パターンを適用するのにまだ苦労しています。これが2010年頃のDDDの状況でした。
DDD is Broken ※ Google翻訳
結局のところ出版から5年以上経ってもドメイン駆動設計の戦術的および戦略的パターンを適用するのは難しかったというのが普及しなかった要因の１つかなと思います。
マイクロサービスとDDD
ではDDDは影を潜めたのかというとそんなことはなく、マイクロサービスの文脈で再度注目を集めます。
彼は Martin Fowler 氏とともにマイクロサービス革命を引き起こし、マイクロサービスの理論的基盤としての DDD への新たな関心を引き起こしました。 ... DDD の境界コンテキスト、サブドメイン、およびコンテキスト マップが役に立ちました。
DDD is Broken ※ Google翻訳
このような背景から、多くの本や教材でDDDはMicroservicesと関連づけられて解説されることが多いです。
たとえばLinkedInのDDD教材でもマイクロサービス、Bounded Contextそれぞれ1章ずつ費やされ、詳しく説明されていますし、マイクロサービスの教材でもDDDの解説が含まれています。
もちろんLinkedIn以外にも色々あります。
Reactive ArchitectureとDDD
2010年代にマイクロサービスが実践される中、より良い方法論が模索されていきます。
特にマイクロサービス同士が同期的にやり取りをするアーキテクチャではサービス同士が密結合になりやすく、スケーラビリティも失われいくため、2014年にReactive Manifestoが発表され、Reactive Architectureの考え方が普及しました。
そしてReactive Architectureにおけるシステム分割単位を見つける手法として、Event Stormingが生まれました。
このあたりはDDDと直接的には関係がないように感じられますが、英語圏だと関連して語られることの多いものです。
実際にMicroservices、Event Storming、Reactive ArchitectureといったキーワードはDDD Europeの公演でもよく目にします。
2020年ごろの日本でのDDDブーム
さて、ここまでの流れとは全く無関係に、2020年前後に突然日本でDDDに関する言及が増えていきます。
これはMicroservices、Reactive Architectureといった文脈とは無関係に、どうコードを書くかの戦術的DDDの部分が特にフォーカスされます。
ここからは完全に体感からくる推測ですが、Ruby on Railsの衰退に関わっているのではないかと思います。
2018年ごろから情報商材屋界隈がエンジニア転職を推し始め、『1年で年収イッセンマン』の標語とともにプログラミングスクールが隆盛しました。
プログラミングスクールでは敷居の低さからRuby on Railsが教えられ、Railsしか書けないジュニアエンジニアが業界に大量に生まれました。
これが「Railsの現場イケてないよね」「Rubyって単価低いよね」みたいな空気につながり、他の言語/フレームワークへの移行が急速に進んだんじゃないかと。
そして多くのフレームワークはRails wayほど道が整ってなく、 多くの設計は自分自身が行う必要が出てきます。
そこで新しい道を求めてる人たちの需要にDDDが合致しんじゃないかと推察します。
おわりに
この記事ではDDDを取り巻く時系列から、DDDをさまざまな角度から見つめ直していきました。
特に日本以外でDDDがどのように扱われているのか知るとことで、新しい視点からDDDを捉えることができました。
DDD自体はできてから20年以上経っている思想であり、無数の実践を経た上で今があると言えます。
こうした歴史を踏まえることで同じ失敗を繰り返さずに、より良い実践に繋げられると思います。
Discussion