『ドメイン駆動設計をはじめよう』がわかりやすすぎた
こんにちは、リファクタリング大好きなミノ駆動です。
2024/07/20に発売された『ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法』を、訳者の増田亨氏よりご恵贈賜りました。
この記事は、この書籍の感想です。
著者の許可を得た上でのだいたんな意訳
総評等の前にいの一番で伝えたいポイントです。
エリック・エヴァンス氏の『ドメイン駆動設計』は大変価値の高い知見が網羅されている一方、「ユビキタス言語」や「境界づけられたコンテキスト」といった独特の用語が登場したり、難しい言い回しをしていたり、読解がかなり難しい書籍です。
独自用語が登場するたびに「ユビキタス言語？なんだこれ？」とつまづきを覚え、内容理解に集中できず、読む手が止まってしまったことがある人も少なくないのではないでしょうか。
本書『ドメイン駆動設計をはじめよう』は『Learning Domain-Driven Design』の訳書ですが、翻訳にあたり著者の許可を得てだいたんな意訳をいくつかしたとのことです（※冒頭「訳者まえがき」に記述あり）。
例えば用語では、「ユビキタス言語」は「同じ言葉」、「ドメイン」は「事業活動または事業領域」といった言葉として表現されています。
このため、変な突っかかりを覚えず自然な感じで読み進められて、内容理解に集中できました。
本書の内容も当然素晴らしいですが、読みやすく意訳したこと自体に間違いなく価値があります。
総評：まるで答え合わせをしているかのようだった
自分がドメイン駆動設計の存在を知ったのは2012-2013年頃だったと記憶しています。
当時の自分は炎上プロジェクトの真っ只中で、設計品質向上のため様々な技術書を買っては読んで試して、の繰り返しでした。そんな流れで手にしたのがエヴァンス本です。
ところが、まあ書いてることが難解で、「これってどういう意味なんだ！？」「自分はこういう理解だと思ってるけど合ってるのか！？」と、当時七転八倒しながら読んでいました。
エヴァンス本は実に不思議な本で、実務を積み重ね、開発の様々な苦労を経て初めて行間が読めるようになるんですよね。
だから実務と照らし合わせながら繰り返して読んで、少しずつ意味を咀嚼していました。何周しても学びのある、スルメ的な美味さのある書籍です。
そして本書『ドメイン駆動設計をはじめよう』、自分がこれまで咀嚼し理解してきた内容と、ガッチリ歯車が噛み合うような一致感がありました。読んでいて、まるで答え合わせしているかのような感覚を覚えました。
こうした理由から、「ドメイン駆動設計ってなんだろう？」と興味のある方は、いきなりエヴァンス本に手を出すのではなく、こちらの『ドメイン駆動設計をはじめよう』から読み進めることをオススメしたいです。
要求を満たせず爆死するソフトウェア開発
本書冒頭の「はじめに」では、要求や意図が不明瞭なために納期遅延や予算超過、ユーザーの役に立たないソフトウェア、といったソフトウェア開発の失敗について述べられています。
せっかくソフトウェアを開発しても、役に立たなければユーザーは使いませんし当然対価は支払われません。複雑で意図の分からない仕様を目の前にただただ開発費は高騰するばかりで、会社からキャッシュがなくなってしまいます。そして我々の給料は上がらなくなります。
競争優位性を発揮する中核業務領域、コアドメイン
エヴァンス本では「どんなに優れた技術で実装しても、何がソフトウェアの重要な部分か意識しないとユーザーに訴求することはない、だからこそ価値のある部分を識別し、その部分の価値が向上するように開発投資せよ（※意訳）」と述べられています。
この部分こそがコアドメインです。コアドメインとは競争優位性を発揮し差別化を図る業務領域です。
よく「ソフトウェアの価値」なんて言い方がされますが、価値とは差異です。競争優位性を高め、差別化することで競合との差異が拡大し、ユーザーにとって魅力的なものになり、ソフトウェアは成功します。
ソフトウェアの成功には、コアドメインに立脚することが重要、ということですね。
ところが当のエヴァンス本、コアドメインの記述はかなり後ろの方なんですよね。せっかくエヴァンス本冒頭で「コアドメインに集中すること」と書いてあるのに、伝わりにくい構成だなぁというのが私個人の感想です。
ドメイン駆動設計に登場するValueObjectやEntityなどの設計パターンだけを真似た、いわゆる「軽量DDD」に陥ってしまうのも、コアドメインの重要性がいまいち伝わっていないのが要因のひとつなのかな、と思ったりするわけです。
第1章がコアドメインの解説だと！？！？
本書『ドメイン駆動設計をはじめよう』を読んでビックリしたのは、第1章でコアドメインを解説していることです。
コアドメインは、本書では中核の業務領域と意訳されています。
第1章では、事業を進める上でなぜ差別化しなければならないのか、差別化する箇所と、そうでない箇所をなぜ区分する必要があるのか、という内容について、中核の業務領域を中心に解説しています。
この章を読むことでドメイン駆動設計を実践する意義を理解できるでしょう。
「ドメイン駆動設計を取り入れてみようとしたものの、軽量DDDに陥ってる（設計パターンを真似てるだけ）かも……」と心配な方は、第1章をしっかり読んで理解することをオススメします。
中核の業務領域が最初にあるから他の概念も理解できる
中核の業務領域において競争優位性の最大化を図るには、ユーザーの真の目的や利害関係者同士の意図の正確な理解が不可欠です。
だからこそ目的や意図を理解するために同じ言葉（ユビキタス言語）を用いたり、また言葉の意味は文脈によって変わるので区切られた文脈（境界づけられたコンテキスト）により文脈を識別することの重要性が、後続する章で解説されています。
また、競争優位の発揮には必然的に問題が複雑化するため、そうした複雑な問題を解決するロジックをカプセル化したドメインモデルが必要になる、という解説にもつながっています。
このように、中核の業務領域が基盤にあるからこそ、ドメイン駆動設計の様々な概念や考え方が理解できる章構成になっています。
目的とドメインモデルの関係
私が設計上大事にしているポリシーがあります。
システムは目的を達成するための手段。
モデルはミクロなシステム、ゆえにモデルも目的達成手段。
モデルはある目的達成に特化した仕組みを備える。
本書第2章などで同じような主旨の解説があったので、答え合わせ感があって個人的に嬉しかったです。
個人的にクスッときたところ
事業への貢献が実証されていて、積み重なった技術的負債と膨れ上がった設計の乱雑さを刷新する必要があるシステムこそ、ドメイン駆動設計で取り組む価値がもっとも高いのです。
まあーーー、そりゃあそうなるよね、と思いましたｗ
私自身、技術的負債の解消やそのための各種設計支援を生業としており、複雑で難攻不落な技術的負債と戦うためにドメイン駆動設計を活用しているので、この記述を見て「これ自分の仕事のことじゃん」と感じました。
本書の活用どころ
せっかく読んだからには何らかの形で業務に活用したいものですね。
もちろん本書全てが活用可能な知見にあふれていますが、自分がさっと感じたところでは、以下の活用の仕方があるのではないかなと考えます。
活用法１：中核の業務領域について議論する
ドメイン駆動設計を導入するか否かによらず、自分たちがちゃんとユーザーに訴求するサービスを開発できているか、まず見直してみる姿勢が大事だと思います。
第1章「事業活動を分析する」をチームで読み合わせした上で、自分たちのサービスの競争優位性は何か、ユーザーが本当に求めているものは何か、そのユーザー目的に合致するサービスを提供できているか、提供できていないなら、どういう形が望ましいか、といった議論をするのが良いと考えます。
活用法２：どこまでDDDを導入するか判断する
DDDの導入にあたり、どう導入するか、どこまで導入するかが悩みのタネだと思います。
実際、設計にはコストがかかるので、単純なCRUDといった大して複雑でもない箇所を豪華に設計しても、構造的にムダが多くなります。
第10章、11章には、状況に合わせてどういう設計を選択すればいいのか判断指針や、別の設計への移行指針について解説しています。
この章を足がかりに導入検討するのが良いかなと思います。
活用法３：イベントストーミングでモデリングし、現状の実装と比較する
第12章では、モデリング手法の一種、イベントストーミングの方法について解説しています。
すでに実装済みの機能のうち、仕組みが複雑で負債化してそうなものに関して、イベントストーミングでモデリングし直してみるのが良いかなと考えます。
既存の実装に囚われず、ゼロベースでモデリングし直してみるのです。
そして現状実装とモデルを比較すれば、ギャップとして負債がどれぐらい酷いか認知できますし、どうリファクタリングすればいいかゴールも分かるでしょう。
ドメインモデルの威力を理解できる良い機会になると思います。
おわりに
ソフトウェアの成功はどのIT企業にとっても最大の関心事でしょう。
ドメイン駆動設計を導入するかどうかはともかく、知っておいて損はないと思います。
エヴァンス本は難解でこれまでハードルが高かったですが、本書『ドメイン駆動設計をはじめよう』は間違いなくハードルを下げる1冊だと感じました。
皆さんもぜひ手にとってみてはいかがでしょうか。
この記事が気に入ったらサポートをしてみませんか？