「ドメイン駆動設計をはじめよう」の感想
はじめに
様々な設計手法がある中、特に注目されている手法に「ドメイン駆動設計」があります。
ドメイン駆動設計はエリック・エヴァンス氏によって提唱された手法で、ソフトウェアが解決すべき「事業活動（ドメイン）」に焦点を当て、ビジネス価値を最大化することを目指したものです。
エヴァンス本と呼ばれる「エリック・エヴァンスのドメイン駆動設計」が有名だと思います。
しかし、エヴァンス本は難しい部分があり、わたし自身も以前読みましたが、十分に理解したとは言えませんでした。
そして、今年「ドメイン駆動設計をはじめよう」という書籍が発行されました。
本書は、最新の技術トレンドを取り入れながら、ドメイン駆動設計の基本概念と実践方法をわかりやすく解説したものとなります。
シンプルかつ実践的な内容で非常におすすめできる書籍です。
今回は読んだ感想をまとめたいと思います。
本書の構成
本書の構成は以下となっています。
第I部 設計の基本方針
1章 事業活動を分析する
2章 業務知識を発見する
3章 事業活動の複雑さに立ち向かう
4章 区切られた文脈どうしの連係
第II部 実装方法の選択
5章 単純な業務ロジックを実装する
6章 複雑な業務ロジックに立ち向かう
7章 時間軸でモデルを作る
8章 技術方式
9章 通信
第III部 ドメイン駆動設計の実践
10章 設計の経験則
11章 設計を進化させる
12章 イベントストーミング
13章 現実世界のドメイン駆動設計
第 IV部 他の方法論や設計技法との関係
14章 マイクロサービス
15章 イベント駆動アーキテクチャ
16章 データメッシュ
結びの言葉
付録A ドメイン駆動設計の実践：事例研究
付録B 演習問題の回答
どのような内容かについては翻訳者の増田さんの下記スライドを参照いただくのがいいかと思います。
各章の感想
各章の概要とX上にてポストした感想をまとめます。
訳語について
本書籍では下記のように従来の訳語とは異なる訳語があてられています。
この訳語によって非常にわかりやすくなっていると感じました。
| 原語 | 従来の訳語 | 本書の訳語 |
|---|---|---|
| domain | ドメイン | 事業活動または事業領域 |
| subdomain | サブドメイン | 業務領域 |
| domain logic | ドメインロジック | 業務ロジック |
| domain event | ドメインイベント | 業務イベント |
| Ubiquitous Language | ユビキタス言語 | 同じ言葉 |
| Bounded Context | 境界づけられたコンテキスト | 区切られた文脈 |
| Context Map | コンテキストマップ | 文脈の地図 |
| Shared Kernel | 共有カーネル | モデルの共有 |
| Anticorruption Layer | 腐敗防止層 | モデル変換装置 |
| Separate Way | 別々の道 | 互いに独立 |
1章 事業活動を分析する
この章は事業活動を理解するためのドメイン駆動設計の考え方とやり方が解説されています。
感想
ドメイン駆動設計は事業活動と構造を理解するところから始まります。
理想的には設計者や開発者が業務全体を完全に理解したうえで設計や開発を進めることが望ましいです。
しかし、現実としては設計者や開発者がすべての業務を完全に理解することは極めて難しいです。
そこで重要となるのがコミュニケーションとなります。
業務エキスパートと密にコミュニケーションをとり、本来の意図を漏れなく汲み取ることがなにより重要になると思います。（どのようにくみ取るかは次章で解説されています。）
この辺りはSIerとして参画する場合に特に必要とされると思います。
いかにステークホルダーを巻き込みながら業務エキスパートとの信頼関係を築けるかが、プロジェクトの成功を左右すると言っても過言ではないと思います。
2章 業務知識を発見する
この章は業務エキスパートと設計者の間にある知識的なギャップを埋める手法である「同じ言葉」について解説されています。
感想
プロジェクト全体を通して同じ言葉を使うことで、意思の伝達と知識の共有が進み、業務知識の発見につながる
これはわたし自身、過去の経験でも感じており、同じ目線でユーザと向き合うことが重要だと考えています。
エンジニアという立場では、気付かぬうちに技術思考となりがちですが、常にユーザ目線を意識したいと改めて思いました。
同じ言葉で同じ目線になって考えること、それが何より重要となります。
3章 事業活動の複雑さに立ち向かう
この章は「同じ言葉」が適用できる文脈である、「区切られた文脈」について解説されています。
感想
区切られた文脈とはなにか、これは理解が難しい部分だと思います。
この定義について本書の「業務領域は発見で、区切られた文脈は設計」という一文でスッキリと理解することができました。
ドメイン駆動設計では、「業務領域」「区切られた文脈」「同じ言葉」の3要素とその関係性を理解することが重要となります。
ここを理解・意識しなければドメイン駆動設計のあるべき姿からどんどん乖離してしまいます。
スケジュールや工数等様々な要因に追われることが多いですが、これらを常に意識し、取り組んでいきたいと改めて思いました。
4章 区切られた文脈どうしの連係
この章は「区切られた文脈」のどうし連携方式とそれを可視化した文脈の地図について解説されています。
感想
ドメイン駆動設計においては区切られた境界の連携方法を明確にしないと、境界の曖昧さや設計自体に影響が出ることがあります。
どのように連携するか、連携をどう管理するかは設計における重要事項と考えています。
ここで紹介された連携方法や文脈の地図をヒントに、プロジェクト特性に合ったベストな方法を探っていきたいと思います。
5章 単純な業務ロジックを実装する
この章は単純な業務ロジックの実装方法である「トランザクションスクリプト」と「アクティブレコード」について解説されています。
感想
一貫性を含むデータの品質を誰がどのように担保し、どこまで許容するかは設計における課題となる事が多いです。
また、データ品質はビジネス上の意思決定や活動に直結する重要な要素となるため、品質を高めるためのアプローチが必要不可欠となります。
データの品質をどう担保するかはData Contracts等様々な手段がありますが、データの提供元となる業務システム側で担保する事も必要だと考えています。
データの品質を意識した設計や実装は経験やスキルに依存する部分が大きいと考えています。
プロジェクト全体で設計や実装におけるガイドラインやベストプラクティスを定義・共有しながら対応することが求められます。
この章のような単純な処理だからと侮らず、確実な設計・実装を行いたいと思います。
6章 複雑な業務ロジックに立ち向かう
この章は複雑な業務ロジックの実装方法である「ドメインモデル」について解説されています。
感想
複雑な業務ロジックを実装するための手段であるドメインモデルについてわかりやすく解説されており、理解することができました。
エンジニアとして働いていると、気付かぬうちに技術的な関心事に着目しがちですが、ドメインモデルを意識し、業務ロジックに焦点を合わせる事を徹底することが必要となります。
特に技術志向のメンバーに注意が必要で、「同じ言葉」を徹底することを忘れてしまい、技術的なアプローチで会話してしまうことが多々あります。
こういった複雑な業務ロジックを扱う際にはより意識して「同じ言葉」を使うことを徹底することが何より重要だと思います。
7章 時間軸でモデルを作る
この章は「イベントソーシング」とドメインモデルの集約を時間軸で行う方法、そして「イベント履歴式ドメインモデル」について解説されています。
感想
イベント履歴式ドメインモデルについては過去の経験からもこの章で記載されているようなメリットとデメリットがありました。（※詳細は本書を読んでもらうのがいいと思います！）
- メリット：タイムトラベル、深い洞察、監査ログ、進化した楽観的排他制御
- デメリット：学習曲線、モデルの発展性、技術方式の複雑さ
デメリットの中でも特に設計の複雑性やデータ構造の変更の手間は開発や運用を行う上で大きな課題となることが多いです。
この部分はプロジェクトを通して設計や変更管理の指針を厳密に定義し、徹底していく必要があると考えています。
デメリットへの対応は必要ですが、監査対応やデータ分析に対応可能なデータを保持できる点は大きなメリットになりえると考えています。
※SIer目線だとシステム開発からデータ分析基盤の構築までまとめて提案できると思います。
ドメイン駆動設計の適用にかかわらずイベント履歴の仕組みは有用だと考えています。
監査対応やデータ分析基盤への対応含めて要件や諸々の特性に応じて採用を検討する価値はあると思います。
8章 技術方式
この章は「レイヤードアーキテクチャ」と「ポートアダプター」、そして「コマンド・クエリ責任分離（CQRS）」について解説されています。
感想
それぞれのアーキテクチャについては知識がありましたが、使いどころに関しては非常に勉強になりました。
ドメイン駆動設計では業務ロジックは何より重要という前提はありますが、技術的な関心事を適切に構造化し、将来的な保守も加味しながら設計することが求められます。
適切な構造化と論理的な境界ごとの技術方式の選定にはいち設計者だけではなくチーム全体の共通理解が必要となります。
共通理解の醸成にはコミュニケーションコストや学習コストがかかりますが、そのコストを惜しまず理解を深めることが所謂「巨大な泥団子」を防ぐことになると考えています。
とはいえ、ドメイン駆動設計に関わらず「あるべき論」や「理想像」に凝り固まってしまうと推進上支障が出ることが多々あります。
業務ロジックを中心に据えた価値創出を目指すということと設計思想を最低限守るということを前提に、プロジェクトやチームの現実に即した形で進めることも必要だと考えています。
9章 通信
この章はシステムの構成要素（区切られた文脈）を連携するための通信方法について解説されています。
感想
構成要素の連携に関してはドメイン駆動設計に関わらず注意を払う必要があります。
特に対向システムが他ベンダとなった場合には仕様や責任分界点等の検討・調整を行い、イベントやデータに不整合が出ないように綿密に設計することが求められます。
また、近年のシステム開発においてはクラウド上で行うことが主流となっており、AWSではAPI Gateway,SQS,SNS等のサービスでシステム間の連携を行うことが多いです。
リトライ処理に関しても自前で実装するよりサービスの機能を使う方が工数及び信頼性ともに有効であると考えています。
そういった背景から、アプリエンジニアとしても各クラウドの主要サービスの知識は必須と考えています。
業務イベントを途切れさせずデータに不整合を出さないという点を意識し、最適な技術選定とソリューションを検討していきたいと思います。
10章 設計の経験則
この章は設計判断の枠組みについて解説されています。
感想
設計判断の枠組みに関しては非常に勉強となりました。
設計は技術者の経験やスキルに依存することが多く、場合によっては設計思想と乖離することもあります。
直感的に設計判断ができる仕組みを設けることで設計思想に則った形に統一できると考えています。
そのためには教育コストやコミュニケーションコストを払って、知識の底上げをすることがベストだと考えていますが、予算や工数等を加味すると難しいことが多々あります。
そういった場合にこのような枠組みは非常に有効であると思います。
この章は非常に有用だと考えており、個人的にもこれをベースに考えてみたいと思います。
おそらくそのままプロジェクトに適用できるものだと思います。
11章 設計を進化させる
この章は事業活動の変化に対応するための手法について解説されています。
感想
事業活動の変化に伴いシステムには追加開発や修正作業が入る事は常であると考えています。
その場しのぎの対応を行ってしまうと巨大な泥団子状態に陥る事もあるため、設計判断を適切に行う必要があります。
その際、進化した事業の境界をどう捉えるかという設計判断が重要となります。
設計判断においては技術的な知識のほか、業務知識が大前提となります。
しかし、設計者の業務知識にも限界があるため、設計者と業務エキスパートが常に連携して業務とシステムをリンクさせることが求められます。
常に業務を中心に据えて考え、変化を恐れずに進化した業務に合わせて設計も進化させることが重要となります。
調整と最適化を繰り返し、業務とシステムを伴走させるアプローチにより、業務とシステムが一体となって成長し、長期的に価値を提供するシステムを構築できると考えています。
ドメイン駆動設計の「価値を生み出すソフトウェア設計には業務知識が不可欠である」という価値観はドメイン駆動設計に限らず、すべての設計手法にも共通の理念であると考えています。
今後もこの理念を常に意識していきたいと思います。
12章 イベントストーミング
この章は業務プロセスをモデリングするためのワークショップである「イベントストーミング」について解説されています。
感想
As-Is分析や業務分析は、ベンダー側がヒアリングと資料化を行い、業務側はその資料を確認するという受動的な進め方になりがちです。
その結果、隠れた業務プロセスの漏れや、本質的な課題を十分に掘り下げられないケースもあると感じています。
この章で述べられているイベントストーミングの枠組みを活用することで、すべての利害関係者が自分事として業務を漏れなく分析し、同じ言葉を用いて共通の理解を得ることができると感じました。
この流れに従って分析を進めることで、文脈の境界を適切に定義することが可能だと考えています。
このイベントストーミングの手法はドメイン駆動設計に限らず、幅広い場面で有用であると感じるため、是非取り入れていきたいと思います。
13章 現実世界のドメイン駆動設計
この章はドメイン駆動設計の考え方とやり方を現実のソフトウェア開発に適用する方法について解説されています。
感想
これまでの経験を振り返ると、「完璧な」ドメイン駆動設計を取り入れるのが難しい状況が多かったと感じています。
特にエンハンス開発では、部分的な最適化が中心となり、理想的なドメイン駆動設計には程遠いケースがしばしば見受けられました。
そういった中でこれまでドメイン駆動設計をどのように適用すべきか悩むことも多かったですが、この章にある 「ソフトウェアの『設計』判断を『事業活動』で駆動するのがドメイン駆動設計である」 という一文に強く感銘を受けました。
この一文はドメイン駆動設計の本質を端的に示していると感じています。
完璧な形にこだわりすぎるのではなく、事業活動にフォーカスして設計を行うことが最も重要であるという根本をこれからも意識していきたいと思います。
14章 マイクロサービス
この章はドメイン駆動設計とかかわりの深いマイクロサービスについて解説されています。
感想
マイクロサービスの設計に関してはその粒度が議論の的となる事が多いです。
ただ細かく分割すれば良いというわけではなく、適切な粒度で設計しなければこの章で指摘されているような「分散した巨大な泥団子」に陥ってしまう可能性があります。
適切な粒度の決定には、ビジネス要件、技術的要件、運用負荷、通信コスト等様々な観点から慎重に検討する必要がありますが、同時に課題となることも多いです。
この章で述べられているドメイン駆動設計に基づいた境界の設計手法は、こうした課題に対処するための非常に大きなヒントになると感じています。
マイクロサービスに限った話ではありませんが、根本としてはテクノロジーではなく、事業活動にフォーカスさせる事がなにより重要となります。
ドメイン駆動設計の考え方を活用しながら、適切な境界を意識したマイクロサービス設計を目指していきたいと思います。
15章 イベント駆動アーキテクチャ
この章はイベント駆動アーキテクチャについて解説されています。
感想
イベント駆動型アーキテクチャは、単にイベントを連携すればよいわけではなく、どのようなイベントをどのような種類で連携するかが重要なポイントとなります。
この設計を適切に行うことで疎結合で柔軟性があり、障害に強いアーキテクチャとなります。
イベント駆動設計にはイベントの定義や種類、ルーティング、信頼性の確保といった多様な観点があります。
ルーティングや信頼性の確保についてはクラウドサービスの機能である程度カバーできますが、イベントの定義や種類については設計課題となることが多いです。
前章と同様にこの章で紹介されているアプローチもドメイン駆動設計に基づいてイベント駆動型アーキテクチャを構築する際に非常に有用な指針となると感じています。
これらの考え方を参考にしながら、より良い設計を目指していきたいと思います。
また、前章のマイクロサービスアーキテクチャや本章のイベント駆動アーキテクチャに限らず、様々なアーキテクチャにドメイン駆動設計の考え方を適用できると感じました。
事業活動と開発運用を一体化させて考えることがすべての基本ということを今後も意識していきたいです。
16章 データメッシュ
この章はドメイン駆動設計の考え方をベースにしたデータアーキテクチャの「データメッシュ」について解説されています。
感想
「データは新たな石油」という言葉が示すように、現在のビジネスにおいてデータの価値は非常に注目されています。
データはビジネスの意思決定に直結するものとなるため、いかに品質の高いデータを効率的に収集するかが重要となります。
それと同時にデータをどのように管理し、ガバナンスを統制するかという課題があります。
このような背景の中で注目されているのが、この章で述べられている「データメッシュ」となります。
データメッシュの構築においては、境界をどのように設計するかが大きな課題となります。
この章で紹介の手法は設計を行う上で大きなヒントとなると考えています。
データプロダクトの単位を区切られた文脈の単位とすることで、データの一貫性やオーナーシップを業務と一体化させることが可能となります。
このあたりの一貫性やオーナーシップの考え方は他の書籍でも同様の事が書かれています。
ただ、データメッシュの実現には様々な課題があるため、なかなか普及に至っていないのが現状です。
海外のフォーラムでもデータメッシュに関しては様々な議論が行われており、データメッシュはほとんどの企業にとっておそらく役に立たないと断言している書籍もあります…
よく言われる課題ではありますが、中央集権的で全体管理を行うことが多い日本企業では、分散型ガバナンス統制やドメインごとに自律したプロダクト構築や維持は難しいと考えています。
文化的、組織的にも大きな変革が必要となり、長期的な計画と予算も必要となります。
また、ドメイン単位での管理に向けてデータマネジメント含むデータリテラシーの教育から始める必要があるため一筋縄ではいかないと思います。
※データメッシュに関しては理想論ばかり語られることが多く、思うことが多々ありますが脱線しそうなので、大きな課題があるということだけにとどめておきます…
とはいえ、本書ではデータメッシュについて概要レベルの説明に留まっていますが、設計判断における重要なポイントにはしっかり触れられていると感じています。
このアーキテクチャを実現するには、ドメイン駆動設計の知識が必要不可欠となると考えています。
データメッシュの前提であるドメイン駆動設計の考え方についてはこの書籍で理解することができたと思います。
これらの知識をベースにデータメッシュのアプローチを改めて検討したいと思います。
ちなみにデータメッシュに関しては以下のような記事を書いているのでお時間のある時に読んでいただけると幸いです。
結びの言葉
この章はドメイン駆動設計の考え方の振り返りと結びの言葉となります。
感想
これまでドメイン駆動設計について漠然とした理解しか持っておらず、十分に活用できていなかったと思います。
しかし、今回改めて学び直すとともに、データメッシュにどのように適用できるかという観点で読み進めたことで、大きな理解が得られたと感じています。
今後、ドメイン駆動設計に基づくソフトウェア開発やデータメッシュを活用したデータ基盤構築に携わる機会があると考えています。
その際には、常に業務を意識し同じ言葉でコミュニケーションしながら開発を進めていきたいと思います。
そして、迷ったときは「業務を意識すること」と「ソフトウェアの『設計』判断を『事業活動』で駆動するのがドメイン駆動設計である」という基本的な原則に立ち返り判断していきたいと思います。
付録A ドメイン駆動設計の実践：事例研究
この章は著者の失敗談やその後の対応、そして教訓について解説されています。
感想
著者の失敗談やその後の対応、そして教訓について非常に学びがありました。
実際にドメイン駆動設計を適用しようとすると様々な課題や問題に直面すると思います。
また、納期や様々な要因に囚われ、ドメイン駆動設計の本質から離れてしまう事もあると思います。
そういった判断に迷う場面では、「業務を意識し同じ言葉を使うこと」と「ソフトウェアの「設計」判断を「事業活動」で駆動するのがドメイン駆動設計である」という基本的な部分に立ち返り判断していきたいと思います。
まとめ
本書「ドメイン駆動設計をはじめよう」は他のドメイン駆動設計の書籍と比較し説明が平易でわかりやすい印象を受けました。（過去他の書籍で挫折した私でも最後まで読むことができました！）
学ぶには少しハードルの高い「ドメイン駆動設計」の入門書としては現時点でベストなものだと思います。
初めてドメイン駆動設計を学ぶ方、そして私のように過去別の書籍で学ぼうとして挫折した方に特におすすめとなります。
時間をおいて読むとまた違った学びがあると考えています。
今後、基本に立ち返る目的で定期的に読み返したいと思います。
皆さんもぜひ読んでみてはいかがでしょうか。
Discussion