『ドメイン駆動設計をはじめよう』の感想
書籍『ドメイン駆動設計をはじめよう ソフトウェアの実装と事業戦略を結びつける実践技法』を読んだので感想を書きます。（訳者の増田 亨さんから書籍をご恵贈頂きました。改めて御礼申し上げます）。
※この本では、DDDの用語について従来の訳語とは異なる訳語が使用されています。当記事では、この本で使用される訳語を用いますが、初出に限り「文脈の地図（コンテキストマップ）」のように括弧書きで従来の訳語を記します。
この本の概要
構成
この本は全4部構成で、16の章と付録から成り立っています。
第I部 設計の基本方針
1章 事業活動を分析する
2章 業務知識を発見する
3章 事業活動の複雑さに立ち向かう
4章 区切られた文脈どうしの連係
第II部 実装方法の選択
5章 単純な業務ロジックを実装する
6章 複雑な業務ロジックに立ち向かう
7章 時間軸でモデルを作る
8章 技術方式
9章 通信
第III部 ドメイン駆動設計の実践
10章 設計の経験則
11章 設計を進化させる
12章 イベントストーミング
13章 現実世界のドメイン駆動設計
第 IV部 他の方法論や設計技法との関係
14章 マイクロサービス
15章 イベント駆動アーキテクチャ
16章 データメッシュ
結びの言葉
付録A ドメイン駆動設計の実践：事例研究
付録B 演習問題の回答
第I部
第I部では、DDDにおいて戦略的設計と言われる領域を探求していきます。ふだんソースコードに慣れ親しんだ開発者にとって、戦術的設計と比較して戦略的設計は理解の難易度が高いのではないでしょうか。ドメイン、サブドメイン、コンテキストなどの横文字が並び、ユビキタス言語のような謎用語が使われることもその要因の一つだと考えらます。この本では、なるべく日本語を用いた新訳が当てられていますので、それに関する認知負荷が下がり、また著者のわかりやすい説明よって一からしっかりと理解していくことができます。
ソフトウェアはビジネスに価値をもたらすことを目的に作られます。正しいソフトウェアを作るためには、企業の事業活動を深く理解する必要があります。企業が事業活動を展開する事業領域（ドメイン）、それを細分化した業務領域（サブドメイン）という構造で事業活動の全体像を捉え、さらに事業領域を三つのカテゴリーに分類します。すなわち中核の業務領域（コアサブドメイン）、一般的な業務領域（汎用サブドメイン）、補完的な業務領域（支援サブドメイン）の三つです。これらのうち、企業に競争優位をもたらす中核の業務領域に対して企業の経営資源を集中的に割り当てようというのが、「戦略」と呼ばれる所以です。
業務領域は事業活動としてそこに存在するものを見出していく行為であるのに対して、区切られた文脈（境界付けられたコンテキスト）は、業務領域における課題をソフトウェアでうまく解決するために境界を区切る行為であり、それは「設計」だとこの本では明言しています。解決空間においてモデルの境界をどう選ぶかは設計判断なので、それは一発で正解がわかるようなものではないし、われわれは頻繁にそれをしくじるんだよなぁ、と思いました。
区切られた文脈を定義することは境界付けを行うという設計行為だという認識を持つと、文脈の地図（コンテキストマップ）に対する見方も変わります。つまり、文脈同士の関係性を俯瞰して見えるようにし、関係する文脈同士がどのような契約に基づいてどう相互作用するのかの設計であるということです。ソフトウェアの設計は最初からうまくいくことは滅多になく、試行錯誤を重ねて得た知識をもとに洗練させていかなくてはなりません。また、時間の経過とともに外部要因の力を受けて変更が必要となることもあります。区切られた文脈、文脈の地図についてもそのような認識を持って設計に取り組むべきであろうと思いました。
第II部
第II部のタイトルは「実装方法の選択」となっていますが、どのような方針に基づいてどの実装方法を取るべきかというのが論点です。つまりアーキテクチャの話です。
DDDならドメインモデルでしょ、と思いがちですが、この本ではトランザクションスクリプト、アクティブレコードの設計の話から始まります。続いてドメインモデル、イベントソーシングの順に説明がなされます。これは、カテゴリー分けした業務領域ごとに、適切な実装方法を選択するべきだという主張によるものです。例えば補完的な業務領域におけるロジックはCRUD処理のようなシンプルなものが多く、そこにドメインモデルパターンを適用しても過剰設計でしかないということです。
その他にもアーキテクチャスタイル（レイヤード、ポートとアダプター、CQRS）や連携方式といったトピックが取り上げられています。
第II部は戦術的な設計を進めるためのビルディングブロックの話であり、これまでDDDを勉強したり業務で取り組んだりしてきた方であれば、概ね理解できている内容ではないかと思います。
第III部
第III部では、実際の開発現場においてDDDを実践していくにあたって、押さえておくとよいプラクティスやパターン、アドバイスがまとめられています。
特徴的なのは10章で、業務領域のカテゴリー、データ構造やロジックの特性に応じてどのような実装方法を選択するとよいかをチャート形式で判別する方法が提示されています。これは著者の過去の経験に基づいた経験則であり、どんな場面でも盲目的に従えばよいというものでもないでしょうが、参考にすることはできるのではないでしょうか。
また、13章はではレガシーシステムとどうやって向き合い、どうDDDを適用していけばよいかが述べられています。世の中のほとんどのソフトウェアはレガシーシステムであり、皆さんの多くが日々向き合って格闘しているものです。レガシーシステムであっても、それが中核の業務領域にあたる、つまり競争優位の源泉なのであれば目を瞑って放置するわけにはいきません。この先も利益を出し続けるためには、立ち向かって何とかしなくてはなりません。まるっとリプレースするような資金や時間がない場合は、中核部分をリファクタリング（リアーキテクティング）していくという選択肢もあるでしょう。
第IV部
第IV部では、DDDに関わりの深いトピックとして、マイクロサービス、イベント駆動アーキテクチャ、データメッシュがそれぞれ章を割いて説明されています。
マイクロサービスの粒度をどうするかという課題はなかなか難しい設計判断であり、失敗談もよく耳にします。この本が提示する指針は、その設計判断に対して大きなヒントを与えてくれるのではないでしょうか。
付録A
付録Aは、もしかするとこの本の中で最も価値のある部分かもしれません。著者が実際にスタートアップ企業においてDDDに取り組んできた軌跡が描かれています。いくつもの失敗を重ねて、より「ましな」設計を見出し、DDDに対する理解をアップデートしていった著者の経験を、読者は具体例を通して仮想体験することができます。
もちろん読者が現場で立ち向かうソフトウェアは千差万別であり、固有の課題に対して固有の解決方法を取らなくてはなりません。私達はこの本の提示する手法や方法をただ教義として盲目的に適用するのではなく、なぜその方法がよいのか（よくないのか）をきちんと理解し説明責任を持ってアーキテクチャを設計しなければなりません。そういった意味で、この付録Aは、本の内容に深みを与えてくれるものだと感じました。
誰が読むべきか
ソフトウェアを設計し、開発するすべての人が読むべき一冊だと思います。
実装方法については全てを理解する必要もないですし、現場で使う機会のないものも多いでしょう。
ですが、第I部で述べられた本質を理解し、自分たちの置かれた状況において適切な実装方法を納得感を持って選択することと、時間の経過に伴いその選択が誤りと気づいた場合には軌道修正が可能なようにしておくことはとても重要だと思います。
読者の開発者としての経験やDDDに取り組んだ経験の多寡によって、この本の読み方は異なってくると思います。経験の少ない読者の場合、一度に全てを理解するのは困難でしょうし、途中で詰まる部分もあるかもしれません。ですが、それはそれで問題ないと思います。理解できたことを、職場の同僚と話し合ったり、実践で試したりしながら理解をさらに深めて、時間が経過してからまた読み直すと新たな気づきが得られることでしょう。
それにしても、この夏は良書の出版ラッシュで、嬉しい悲鳴です！
この記事が気に入ったらサポートをしてみませんか？