読んだ本
エリック・エヴァンスのドメイン駆動設計
結論
本書が伝えたいことをどシンプルに言うと「ビジネス（＝ドメイン）をよく理解して、それを軸にシステムを設計しましょう。そうしないと複雑な要件下では見当違いのシステムになってしまうよ。やり方は色々挙げてるから参考にしてね。」ということと理解しました。
以下、感じたことや読み取った内容のまとめです。
- 難しすぎて一回読んだだけではしっかりと理解できなかった
- 具体例を交えて説明がなされているので、頑張って読めば雰囲気ぐらいは分かる
- ドメイン駆動設計とは、ビジネスなどのドメインをモデルに落とし込むことでソフトウェアの作りを決定すること
- モデル駆動設計を含んでいる
- ドメインへの理解の重要性は軽視されがち
- 開発者はドメインエキスパートと協力してドメインをモデルへ落とし込む
- アナリティスパターン、ドメインパターン、デザインパターンは複合的に適用できる
- 境界づけられたコンテキストにより、モデルの複雑さを軽減する
難しすぎて一回読んだだけではしっかりと理解できなかった
身も蓋もないのですが、正直内容が難しくて一通り読んだ段階でも雰囲気レベルでしか理解できませんでした。一応雰囲気レベルで分かった内容でこの感想記事はまとめます。
一応理解出来なかった原因として気づいたことを言うと、本書のあちこちで実例としてモデルの図が出てくるのですが、その内容と文章の説明を読んでるだけで理解が難しいです。恐らくですがそもそも私がモデリングのスキル自体足りていないからだと思っています。ドメイン駆動設計の前にモデル駆動設計から入ったほうが良さそう？
ただ、本を読む目的は自分が知らない概念について体系的に知ることです。なので具体的な詳細が分からなくても抽象的な概念が分かればとりあえずはいいかなと思ってます。とはいえ読み返して理解度を上げたいところ・・・。
ドメイン駆動設計とは
「ドメイン駆動設計とは何か」と聞かれても、本書を読む前の私は正直うまく答えられなかったです。今も自信を持って答えられるわけではないですが、とりあえず見当違いでない回答はできそうです。
結論を出す前にキーワードを整理します。
- ドメイン ... 取り扱う業務領域や問題領域。特有の知識や概念、ルール、手続き、文化、言葉などを含んだ領域。
- 〇〇駆動設計 ... 特定の要素を軸・起点に行う設計
- モデル ... システムの振る舞いやビジネスルールなどの概念を抽象化して表現したもの
つまりドメイン駆動設計とは、取り扱う領域（ドメイン）について整理して、そこを起点にソフトウェアを設計することです。また、ドメインを整理する過程としてモデルを作ります。そのためモデル駆動設計の要素も含んでいます。
具体例
- 開発対象
- 飛行機のチケット予約システム
- モデル
- 飛行機
- 飛行計画
- 空港
- 予約情報
- 購入情報
- ...
飛行機のチケットを予約するシステムにおいて、それぞれのモデルに必要な要素があります。飛行機には席、飛行計画には出発日・経路などの情報が必要でしょう。空港にはどの経路に含まれるかと言った情報が必要そうです。予約情報にはどの空港からどの日程のどの飛行機でどの席に座るかなど詳細な情報が含まれると思われます。
一見当たり前のことを言っているように見えますが、この整理が大事です。「飛行機のチケットを予約する」という文脈と「移動機械のカタログを管理する」という文脈ではどちらも飛行機が出てくるはずですが、それぞれに必要な情報は全く異なるはずです。つまりシステムの目的によって一見同じ要素でもモデルの内容は全く異なるということです。そのため対象のドメインに最適化したモデルを設計する必要があるのです。
本書ではこれらの整理から行われているので、基本概念を正確に理解できます。
ドメインへの理解の重要性は軽視されがち
しかし、たいていのソフトウェアプロジェクトでは、ドメインに関係した問題の解決が重要視されない。有能な開発者のほとんどは、自分の手がける特定のドメインについて勉強する気があまりなく、ドメインモデリングのスキルを真剣に伸ばすつもりはさらにない。
エリック・エヴァンスのドメイン駆動設計 p.4 ソフトウェアの核心
複雑なソフトウェアを開発する上でドメインに対して正面から向き合うことは必須です。ですが、多くのプロジェクトではドメインの課題がさほど重要視されていません。
また、引用にある通り開発者の多くは可搬性の高い定量化可能な領域を好むため、ドメインは他の人に任せたいと思ってしまいがちです。しかし、開発者はドメインのモデリングのスキル高め、自身でドメインに深く取り組むことが大切です。そうでないとソフトウェアは本来の目的を実現しきれない的外れなものになってしまうからです。
この本書の主張はその通りだと思います。逆に言えばこのスキルを高めればエンジニアの中で存在感を高められそうですね。
開発者はドメインエキスパートと協力してドメインをモデルへ落とし込む
多くのシステム開発は既存のビジネス業務を落とし込むものであると思います。つまり現在業務を実際に行っている人達がいて、それらの人達こそ各業務領域について一番深く把握しているのです。また、外部で同じ領域に深く携わっている人も同じことが期待できます。これらの人達はドメインエキスパートと呼ばれ、特定の分野においてトレンドやニーズ、問題点や解決策について深く理解しています。
しかし、実際の開発ではそれらの人達の意見が注意深く拾われ、開発者の疑問点を直接ぶつけて対話するようなことはあまり出来ていないことも多いと思います。それはそれぞれの前提理解の度合いや関心の範囲が異なり、開発を行うエンジニアからすると「現場の人に開発に関して話しても分かって貰えないだろう」という気持ちがあることも要因と思われます。また、意思決定を行う人がそもそもこれらのプロセスの重要性に気づいていないこともありそうです。
より効果的で実際的なシステムを開発するためには、ドメインのモデルをエンジニアとドメインエキスパートで相談・議論しながら最適化していく必要があります。そのための手段としてユビキタス言語という両者にとっての共通言語を定義することがあります。
これはプロセスとしてはすぐにでも実践できるものであり、とても価値のあることなので出来ていなければすぐにやったほうがいいと思います。私の働いている会社でも完全とは言えないながらも実践しています。
アナリティスパターン、ドメインパターン、デザインパターンは複合的に適用できる
ここでもまずキーワードの整理をします。
- アナリシスパターン ... 過去に多くの検討・議論を経て考えられた、新たな開発における出発点として有用なパターン
- ドメインパターン ... 特定の業界やドメインにおいて頻繁に起こる問題を解決するための再利用可能な問題解決策のパターン
- デザインパターン ... 技術的な問題解決のための汎用的で再利用可能な設計のパターン
アナリシスパターンはそのまま適用できることはほぼないですが、盲点になっている部分に対する気づきを与えてくれるものです。各パターンは関心のレイヤーが違っていて、複合的に適用できるケースは多々あります。
〇〇パターンって付いているとどう違うのか気になってしまうのが人の性なので本書で読み取った内容で整理してみました。
境界づけられたコンテキストにより、モデルの複雑さを軽減する
「境界づけられたコンテキストって聞いたことあるしなんかかっこいい響きだけど、正直よくわからん」っていう人いるんじゃないでしょうか。私はこれでした。
なんでこんな概念が必要かというと、一つのモデルに対する捉え方は同じビジネスにおいても立場や状況によって変わるからです。例として商品というモデルに対して営業担当者は価格やスペックを見ます。配送担当者は重量やサイズ、配送考慮事項などを見ます。そのため単純に一つのモデルに対してデータやロジックを詰め込むと大変カオスな状態になりうるわけです。
これらの課題に対して出てくる概念が境界づけられたコンテキストとなります。コンテキストごとにモデルを分けてしまうのです。でも先程の例でいうと本来商品は一つのものであり、システム全体を設計する上で無関係にはする事はできません。そこでさらに出てくるのがコンテキストマップです。コンテキストマップによってコンテキストを跨いだ関連を表現することで、全体を俯瞰して見るのに役立ちます。実装においてはコンテキストごとにAPIでインターフェイスを用意して、必要な情報のやり取りを行うことが多いようです。
おわり
今回は内容が難しかったので感想記事を書くにあたって本を読み返したり、各概念を調査・理解する過程が必要でした。ただ、そのおかげで雰囲気程度だった理解の解像度が上がりました。やはりインプット＆アウトプットで脳 内整理されて理解に繋がりますね。
大変難しい内容ですが、レベルの高いソフトウェア開発者を目指す上で必読と言っても過言ではない、とても有益な本でした。まだ概念を知っただけなので、実際に設計・実装を行う中でどのように取り込んでいけるのか確認していきたいと思います。
本の感想シリーズ第6弾でした。過去の感想記事も良ければ読んでみてください。「本を読んだ感想」タグから参照できるようになってます。
