アジャイルに一貫したモデリングから実装を維持する方法を知る本(エリック・エヴァンスのドメイン駆動設計)

今回は、私にとってのソフトウェア設計に関するバイブル本の一つをご紹介します。

エリック・エヴァンスのドメイン駆動設計

エリック・エヴァンス  (著), 今関 剛 (監修), 和智 右桂  (翻訳), 牧野 祐子 (翻訳)


タイトルの通り、著者のエリック・エヴァンスさんが「ドメイン駆動設計」について、熱く語る本です!

英語版の初版は2003年(日本語版は2011年)に出版されているようなので、意外に歴史のある本ですが、その後の有名な本でも多くで引用されて、今でも影響力の大きい本の一つだと思います。

その理由の一つとして、時代とともにソフトウェアが大規模化、複雑化が進むと同時に、アジャイル開発プロセスやマイクロサービスなどの考え方が普及したこともあり、それに対応できる設計手法(考え方)が求められているからだと思います。

ドメイン駆動設計(domain-driven design, DDD)については、Wikipediaやネット上に多くの解説や情報があります。
しかし、エリック・エヴァンスさんの教え?(ドメイン駆動設計の本質)をちゃんと理解しようと思えば(というより、仕事で複雑性に対応する設計ができるようにするためには)、この本を熟読して、書かれていることを自分なりに「かみ砕くこと」だと思います。(この本を読み返す毎にそう思います。)

設計パターン本のような体裁も持ちあわせていますが、この本の凄さは、パターンカタログというより、「設計道」の啓蒙書(あるいは思想書?)のような側面だと思います(笑)。

約500ページ強の大著にもかかわらず、文章一つ一つに説得力があり(読み返すごとに気づきがある)、さらに文章も熱くて(「~しなければならない」という口調が多い(笑))、修行僧になったと錯覚するくらい身が引き締まります(笑)。

<本の内容>

まえがきに「本書が提供するものは、設計上の意思決定を行うためのフレームワークと、ドメイン設計について議論するための技術的な語彙である。」と書かれています。

しかし、これでは分かり難いので(笑)、もう少し具体的に内容を見ていきます。

この本の序文は、あのマーティン・ファウラーさんが書かれています。この序文もすばらしく、ドメイン駆動設計の趣旨をうまく書かれています。全文を掲載するわけにはいきませんので、その一部を抜粋します。

  • 人間の行う入り組んだ仕事を何らかの形で自動化しようとすれば、ソフトウェアはそこにある複雑さを割けて通ることができない。できるのは、コントロールすることだけだ。複雑さをコントロールする秘訣は、優れたドメインモデルにある。
  • ドメインモデリングの技法そのものに関する語彙を記述し、構築すること。そして、基準となる枠組みを提供することにより、ドメインモデリングという活動を説明し、同時に、この習得困難なスキルを教えられるようにすること。
  • ドメインモデリングにおいては、概念を実装から切り離してはならない。概念が実装から切り離せない理由の一端には、実装上の問題を考慮せずには役に立つ概念モデルを構築することができない、ということもある。しかし、概念と実装を一緒に考える一番の理由は、ドメインモデルの最大の価値が、ユビキタス言語を提供し、ドメインエキスパートと技術者を結びつけることである、ということだ。
  • 真に強力なドメインモデルは時間とともに進化するということであり、偉大なベテランモデラであっても、再考のアイディアを得られるのはシステムが初期リリースされた後のことだ、ということである。


また、少し話がそれますが、ドメイン駆動設計より前に出版されたマーティン・ファウラーさんの著作「エンタープライズアプリケーションアーキテクチャパターン」の9.2ドメインモデル/参考文献に以下のような記述があります。
  • 「Eric Evansも、最近では、ドメインモデルの構築に関する書籍を執筆中だ。私は本書執筆中のためまだ初期段階の原稿しか見ていないが、内容はかなり充実しているようである。」

さて、マーティン・ファウラーさんの言葉の後で私がこの本の内容について書くのは大変おこがましいのですが、自分のブログなので、現時点での私の理解も書いておくことにします。
(非常に内容の濃い本なので、私の力量では簡単に要約することが難しいのですが、逆に、簡単に要約してしまうのは大変もったいない、とも感じています。)

現時点で私が認識しているドメイン駆動設計の骨格?は以下のようなものです。

本のサブタイトルにある通り、「ソフトウェアの核心にある複雑さに立ち向かう」ために、
  • モデル駆動で、分析=設計=コードを一貫したものにする。
  • ユビキタス言語でモデルの概念を支える。
  • モデルのリファクタリングを継続して行ってモデルを成長させる(アジャイル開発)。
    • 開発がイテレーティブであることと、開発者とドメインエキスパートが密接に関わっていること
さらに、「本書は、オブジェクト指向設計の解説書でもなければ、急進的な設計原理を提案することもない。ドメイン駆動設計は、伝統的ないくつかの考え方を基に、強調する点をずらしているのだ。」と書かれています。

つまり、既存の手法に対して、ドメイン駆動設計の観点からの解釈や応用が述べられています。とはいっても、既存の手法(書籍など)を予め理解していないと読み進めないというものではありません。
参考までに、この本の中で言及されている主な既存手法(の書籍)は以下のものです。

ちなみに、上記の書籍はどれも有名な本ばかりで、ドメイン駆動設計が出版された後に改定版が出ているものもあります。プログラミング言語の系譜のように、参考文献をたどると設計手法の系譜も作れそうですね。

さて、この本は4部構成になっています。
  • 第1部 ドメインモデルを機能させる
  • 第2部 モデル駆動設計の構成要素
  • 第3部 より深い洞察に向かうリファクタリング
  • 第4部 戦略的設計

大雑把な話の流れとしては、基本的な考えから始まって、そこからさらに複雑化、大規模化に立ち向かうパターンに進むという感じです。(アジャイル的ですね。)

<感想>

例えば業務システムなどの、それなりの規模のソフトウェアを開発しようとすると、どうしても最低限のモデル(設計といえるもの)は必要だし、かといって、ちゃんとしたモデルを最初から作るのは難しいため、まずは動くものを作って、リファクタリングを繰り返してモデルの形作っていくということも必要になります。

モデルが先か、コードが先か、は鶏と卵のような関係ですが、私のような凡人には、どちらも難しいので、そこは深く考えず(笑)、モデルのイメージが浮かぶものはモデルから入るし、モデルのイメージが湧かなければ、まずは作ってみる感じで進めます。

ただ、どのように始めたとしても、業務システムのような長く使われるソフトウェアでは、作って終わりという事はあり得ず、機能追加などが継続的に行われていくため、複雑性をコントロールする戦略は必要です。その点で、モデル駆動で分析、設計からコードまで一貫してモデルを維持するという考え方はとても納得がいきます。(現実は、そう簡単には行きませんけど(涙))

書籍『人月の神話』に、「コンセプトの一貫性こそが重要だといいたい」という一説がありますが、これに通じるものを感じます。

続いて、アジャイルな設計という観点で読み進めてみると、イテレーティブに開発を進めていく過程でつきあたる問題(システムの複雑化など)に立ち向かうためのリファクタリングに関するパターン本という読み方もできると思います。

加えて、自分にとってはUML図やドキュメントに関する記述も参考になりました。

例えば、この本を読む前は、UML図をどの程度まで詳細(あるいは厳密に)書くべきか?というモヤモヤがありました。

この本の中では「設計に関する本質的な詳細は、コードにおいてとらえられる」とか「常に覚えておいて欲しいのは、モデルは図ではない」などと書かれています。図はコミュニケーションの手段であり、考え方の骨格という位置づけです。

まさにアジャイル的な考え方だと思いますが、私のモヤモヤは、この本を読んであっさり解決しました(笑)。同様にドキュメントとコードの関係も、とても参考になります。

ところで、この本を初めて読んだころは、オントロジーやSemanticWebが流行り始めて少し勉強していた時期だったので、ドメイン駆動設計のアジャイル的な側面より、ユビキタス言語や概念の構成方法の方に主な興味がありました。

この本はオブジェクト指向パラダイムを中心に書かれてはいますが、「Prolog言語もモデル駆動設計と自然に適合する。この場合、パラダイムにあたるものは論理で、モデルは論理学上のルール群とそれらが作用するファクトの集合となる。」とも書かれており、何だか嬉しかった記憶があります(笑)。

私は専門家ではないので自信はありませんが、ドメインエキスパートと開発者がユビキタス言語をもとにモデルを作るという考え方は、(昔の)人工知能分野でエキスパートシステムを作る際に、ナレッジエンジニアが重要視されていたのと似ている気がします。また、オブジェクト指向設計が登場してからドメイン駆動設計への流れは、知識工学からオントロジーの流れにも似ているような気がします。どちらにしても、現実に対してより深いモデルに進んでいるように思いました。
もっとも、昔のエキスパートシステムの衰退原因なども考えると、ドメイン駆動設計(特にユビキタス言語の利用など)も銀の弾丸ではないことはわかりますが。。。

最後に、印象に残った言葉をメモしておきます。とはいっても、メモしておきたい文章が多すぎて絞り切れないので、モデリングの勉強に対するモチベーションに関するところに絞ります。
  • 初歩的なスキルを持ったプログラマを大勢集めても、ある種のソフトウェアを作り出すことはできるが、そうやって作れるものは、土壇場にある企業を救い出せるような類のものではない。
  • 「すべてはオブジェクトである」と言って止めてしまうのは、大工や建築家が家のことを要約して、「すべては部屋である」と言うようなものだ。

以上、長々と書きましたが、私は未だに、この本に書かれていること全てを「かみ砕いて」いるとは思えない状態です。
この本は、ある意味で哲学書?のような抽象度が高い記述になっているので(パターン本という性質上、抽象的な記述になるのかもしれませんが)、時代に応じた解釈も可能でもあり、今後も時代を超えて通用する本だと思っています。

今でも仕事で難しい問題に直面すると、この本によく出てくる「~に立ち向かわなければならない」という表現に、背中を押してもらっています(笑)。

関連記事


コメント

このブログの人気の投稿

VirtualBoxのスナップショット機能

Google Document AIで画像から表形式データを抽出する(Vision API OCRとの違い)

Ubuntu/Colab環境でPDFファイルのページを画像化する(pdf2image、pdftoppm、pdftocairo)