なんとなく参加した増田さんのオンラインセミナで話を聞いて気になってしまったので購入して読んでみました。
概要
サブタイトル「ソフトウェアの実装と事業戦略を結びつける実践技法」に「実践」という言葉が含まれているとおり、事業で利用するシステムやソフトウェアの全てに対して理想的に設計＆実装するのではなく、市場において競争優位を生み出す事業の中核となるドメインを見極めて、限られた経営資源を戦略的に集中させることを目的としています。単なる技術的なハウツー本ではなく、事業を理解して勝負どころや費用対効果を見極めて方法論を適切に使い分けるという点に主眼が置かれているのが特徴です。
感想
これまで、ドメイン駆動設計に関する書籍は「エリック・エヴァンスのドメイン駆動設計」をはじめ様々な書籍が発売されてきましたが、なんとなく敷居が高く理解も難しいものが多かったように思います。それらと比較すると、本書は大きく立ち往生してしまうこともなく、一気に本を読み進めることができました。本を読む前に前述のオンラインイベントで翻訳者である増田さんの話を聞いていたことも大きかったかもしれませんが、それを差し引いて考えてみても、これまでの書籍よりも相対的に読みやすく、より実践的な内容になっていると思えました。
参考
本書を読んでみて印象に残った点を中心に以下に書き留めておきます。
印象に残った点
印象に残ったフレーズや共感できた点などを以下にメモしておきます。
第Ⅰ部 設計の基本方針
１章 事業活動を分析する
1.2.2.3 変わりやすさ
【Page：11】
"前にも書きましたが、中核の業務領域は頻繁に変更されます。1回の開発で簡単に解決できる課題なら、おそらく競争優位の源泉にはなりません。そういう解決策では、競合他社がすぐに追いつくでしょう。ですから、中核の業務領域を対象にしたソフトウェア開発は、創発的な活動になります。さまざまな実装方法を試し、改善し、最適化することが必要です。もっといえば中核の業務領域のソフトウェア開発に「完了」はありません。企業は中核の業務領域を常に革新し進化させます。その変化はソフトウェアへの機能追加だったり既存機能の最適化だったりします。どちらの方法でも、中核の業務領域を持続的に発展させていくことが、競争優位を維持するために絶対に必要です。"
1.2.3 変わりやすさ業務領域の境界を明確にする
【Page：13】
"業務領域の特徴をしっかりとらえ、中核、一般、補完の三つのカテゴリーに分類することは、ソフトウェアを開発する時のさまざまな設計判断にかなり役立ちます。"
1.2.3.3 重要なところに焦点を合わせる
【Page：17】
"業務領域は設計判断をやりやすくするための道具です。どの組織でも、ソフトウェアが関係しない業務機能が競争優位の源泉となっていることが少なからずあるでしょう。たとえば、さきほど検討した宝飾品メーカーのデザイン業務です。業務領域を探す時は、ソフトウェアに関係しない業務を識別できれば、取り組んでいるソフトウェアシステムが対象とする業務領域に集中できます。"
1.4 業務エキスパート
【Page：21】
"業務エキスパート（ドメインエキスパート）とは、ソフトウェア開発の対象となっている業務領域の活動に精通した人たちです。ソフトウェア開発者がモデルを作成しプログラムを書こうとしている対象業務の込み入った内容を熟知している人たちです。別の言い方をすれば、業務エキスパートは対象領域について信頼できる情報源です。業務エキスパートは要求を分析し整理する専門家ではありません。システムを設計する専門家でもありません。業務エキスパートは業務領域の活動の代弁者です。"
２章 業務知識を発見する
【Page：25】
"この章で学ぶのは、意図を適切に伝え、知識を共有するためのドメイン駆動設計の基本的な道具である同じ言葉（Ubiquitous Language）です。"
2.3 意図の伝達
【Page：27】
"ソフトウェア開発プロジェクトが失敗した原因を調査した報告書によれば、効果的な意図の伝達は、知識の共有とプロジェクトの成功に不可欠です。"
2.4 業務で使う言葉
【Page：30】
"同じ言葉は業務で使う言葉です。この点はきわめて重要です。同じ言葉に含まれるのは業務用語だけです。技術用語を含めてはいけません。（中略）同じ言葉の目的は、業務エキスパートの頭の中にある事業活動についての知識や考え方を、わかりやすく整理することです。"
2.6.1 モデルとは何か
【Page：32】
"
モデルとは、現実のモノや出来事を簡略化した表現です。特定の側面を意図的に強調し、一方で、それ以外の側面を意図的に除外します。モデルは用途を限定した抽象化です。
ーーレベッカ・ワーフスブラック
モデルは現実世界のコピーではありません。現実世界の仕組みがどうなっているかを理解するための作り物です。"
2.6.2 効果的なモデル
【Page：33】
"モデルには必ず目的があります。役に立つモデルはその目的にそった内容だけを表現します。たとえば世界地図に地下鉄の駅は不要です。一方で地下鉄の路線図からは正確な距離を知ることはできません。どの地図もその目的に合致する情報だけを提供します。この点はきわめて重要です。（中略）モデルは抽象化です。抽象化とは、複雑さをうまく扱うために、課題解決には必要としない詳細を取り除き、課題解決に必要な部分を抜き出す活動です。"
３章 事業活動の複雑さに立ち向かう
3.1 異なるモデルの混在
【Page：41】
"「あらゆることに手を出すと、どれもちゃんとできない」という格言があります。一つの大きなモデルは、すべてを表現できそうです。しかし、最終的には、どんな用途にも役に立ちません。こういう大きなモデルは何をやるにしてもやっかいです。当面の用途に不必要な大量の詳細を取り除き、本当に必要な情報を発見することはたいへんです。そもそも、こういう大きなモデルを常に最新の状態に保つことはできないでしょう。"
3.2.2 同じ言葉の定義（改良版）
【Page：44】
"区切られた文脈（Bounded Context）によって同じ言葉（Ubiquitous Language）の定義が完成します。ドメイン駆動設計の「同じ」言葉は組織全体で統一した言葉を使うという意味ではありません。同じ言葉は広い範囲で通用する共通言語ではありません。
そうではなく、同じ言葉が通用する範囲は、区切られた文脈の境界の内部に限定されます。"
3.3.3 業務領域と区切られた文脈の対応
【Page：49】
"一つの業務領域であっても課題が複数あれば、別々のモデルを作るほうがよいでしょう。業務領域と区切られた文脈の対応を一対一に限定してしまうと課題解決の柔軟性が失われてしまいます。一つの業務領域に一つのモデルという固定観念は持たないでください。"
４章 区切られた文脈どうしの連係
4.1.1 良きパートナー
【Page：61】
"良きパートナーの関係で連係するには、二つのチームが協力することに習熟し、目標の達成に強い意欲を持ち、頻繁に同期を行うことが必要です。技術的には、それぞれのチームが継続的インテグレーションを頻繁に実施することで、連係に関わる問題の発生を最小にします。
良きパートナーの関係は物理的に離れたチームどうしでは難しかもしれません。同期や意図の伝達にいろいろな工夫が必要になるでしょう。"
4.1.2.3 モデルを共有するかどうかの判断
【Page：63】
"モデルを共有するかどうかは慎重に判断してください。モデルの共有は、やむを得ず使うことがある例外的な連係方法です。たとえば、物理的に離れている、あるいはチーム間で組織の利害関係が衝突している場合です。このような状況では、良きパートナーのような、円滑な意図の伝達と協力体制は期待できません。"
第Ⅱ部 実装方法の選択
５章 単純な業務ロジックを実装する
5.2.2 アクティブレコードをいつ使うか
【Page：85】
"アクティブレコードも本質的にはトランザクションスクリプトです。アクティブレコードの主たる目的はデータベース操作の最適化です。ですのでアクティブレコードの用途は、CRUD操作と入力値の妥当性検査のような、比較的簡単な業務ロジックに限定されます。
つまりアクティブレコードを使うのは、トランザクションスクリプトと同じく、以下の場合です。
- 補完的な業務領域
- 一般的な業務領域用の外部サービスとの連係
- 区切られた文脈どうしを連係する時のモデルの変換
（中略）しかし、私は「貧血」とか「アンチパターン」という否定的な扱い方は避けたいと思います。アクティブレコードは一つの手段です。どんな手段でもそうですが、使い方によっては役に立つはずです。
🐦️ここで説明しているアクティブレコードは設計パターンです。ORMフレームワークのActive Recordではありません。設計パターンとしてのアクティブレコードは、マーチン・ファウラーが『エンタープライズアプリケーションアーキテクチャパターン』（翔泳社）で紹介しました。この設計パターンの実装方法の一つとして後から生まれたのがフレームワークとしてのActive Recordです。この本で説明しているのはアクティブレコードという、設計の考え方です。特定の実装方法を取り上げているわけではありません。
"
７章 時間軸でモデルを作る
【Page：117】
"イベント履歴式ドメインモデルでは、イベントソーシングを使って集約の状態を管理します。つまり、集約の状態を永続化するのではなく、集約の状態が変化したことを業務イベントで表現し、業務イベントの履歴を「真実を語る唯一の情報源」（the source of truth）として永続化します。"
7.1 イベントソーシング
【Page：117】
"
フローチャートを見てもテーブルを見ないと何もわかりません。テーブルのデータを見ればフローチャートを見る必要はありません。
ーーフレッド・ブルックス（邦訳『人月の神話』ピアソンエデュケーション、2002年）
"
7.1.3 真実を語る唯一の情報源
【Page：126】
"イベントソーシングを実現するには、オブジェクトのすべての状態変更をイベントとして表現し、永続化することが必要です。永続化されたイベントが「真実を語る唯一の情報源」（the source of truth）となります。つまりイベント（event）ソーシング（sourcing）です。"
7.2 イベント履歴式ドメインモデル
【Page：130】
"「イベント履歴式ドメインモデル」という用語にした理由
「イベントソーシング」ではなく「イベント履歴式ドメインモデル」という用語にした理由を説明させてください。状態の遷移をイベントで表現するイベントソーシングは、さまざまな状態管理に適用可能です。イベントソーシングの適用対象は、ドメインモデルの部品である集約の状態管理に限定されません。そのため、集約のライフサイクルの状態管理にイベントソーシングを使っていることを明示するためには、イベント履歴式ドメインモデルという長い用語のほうが好ましいと考えました。"
7.2.2 欠点
【Page：132】
"イベント履歴式ドメインモデルは、業務ロジックを実装する究極のやり方であり、できるだけこの方法を使うべきだと思うかもしれません。もちろん、こういう単純な味方は「事業活動の視点で設計判断する」という原則から外れます。"
８章 技術方式
8.2.3 データアクセス層
【Page：142】
"データアクセス層は、永続化の仕組みと接続する機能を提供します。もともとは、データベースを指していましたが、プレゼンテーション層の場合と同様に、現代のシステムではデータアクセス層の責務は広がっています。"
第一に、NoSQLによる永続化方式の革新と急激な普及によって、一つのシステムで複数のデータベースを利用することが一般的になってきました。（中略）
第二に、従来のデータベースだけが情報を格納する媒体ではありません。たとえば、クラウドベースのオブジェクトストレージ（AWSのS3やGoogle Cloud Storageなど）を使ってシステムのファイルを保存したり、メッセージ通信基盤を介してプログラム間の通信を制御したりできます。
さらには、このレイヤーでは、プログラムの機能を実現するために、外部のさまざまな情報源と連係します。つまり、外部システムのAPI、あるいはクラウドのマネージドサービスとして提供される、翻訳、株式市場データ、音声転写などとの連係です。"
8.2.6 レイヤードアーキテクチャをいつ使うか
【Page：148】
"補足：レイヤーとティアの違い
レイヤードアーキテクチャはN層（N-Tier）アーキテクチャとしばしば混同されます。そしてその逆もまた然りです。この二つの方式は似ていますが、レイヤー（Layer）とティア（Tier）は異なる概念です。つまり、レイヤーは論理的な境界です。ティアは物理的な境界です。レイヤードアーキテクチャのすべてのレイヤーは、同じライフサイクルで変化します。つまり、レイヤーの集合が単一のユニットとして実装され、進化し、デプロイされます。"
９章 通信
9.1 モデルの変換
【Page：163】
"区切られた文脈はモデル、つまり同じ言葉の境界です。"
9.2.2 サーガ
【Page：175】
"サーガとは、開始から終了まで長く続く業務プロセスです。「長く続く」という意味は、必ずしも時間の絶対的な長さではありません。秒単位で終わるサーガもあれば、年単位で続くサーガもあります。重要なのはトランザクションの視点です。つまり、多数のトランザクションで構成される業務プロセスがサーガです。
[訳注]サーガはもともとは北欧神話の壮大な英雄物語のこと。転じて、複数の状態管理を大がかりに行う仕組みを指しています。"
第Ⅲ部 ドメイン駆動設計の実践
１０章 設計の経験則
10.1 経験則
【Page：188】
"同じ言葉を一貫して使うために、区切られた文脈を広く区切ることも、狭く区切ることもできます。では、区切られた文脈の「最適な大きさ」とは何でしょうか。この問いかけは、区切られた文脈とマイクロサービスがしばしば同一視されることを考えると、特に重要です。区切られた文脈はできるだけ小さく区切るべきでしょうか。私の友人であるニック・チューンは、次のように言っています。
サービスの境界を決める時に役に立つわかりやすい経験則がたくさんあります。「大きさ」はもっとも役に立たないものの一つです。
区切られた文脈の大きさを決めてからモデルを作ってはいけません。役に立つのは逆のやり方です。つまり、モデルを作ってから区切られた文脈の大きさを決定します。"
10.4 技術方式の選択
【Page：192】
"どの技術方式を選択するかの経験則にもとづく判定方法は図10-4のとおりです。
10.5 テストの基本方針
【Page：194-195】
"業務ロジックの実装方法とシステム構築の技術方法がわかれば、テスト方針を選択するための経験則としても使えます。テスト方針の三つの選択肢を見てみましょう（図10-5）。
（中略）テスト方針の判定方法は図10-6のようになります。
１１章 設計を進化させる
11.4.1 良きパートナーから利用者と供給者の関係へ
【Page：210】
"良きパートナーはチーム間の意図の伝達と協力がきわめてうまくいっている場合に成り立ちます。しかし時間がたつにつれて、うまくいかなくなるかもしれません。たとえばどちらかの区切られた文脈を遠く離れた別の拠点のチームが開発することになった場合です。そういう開発体制の変化は、チーム間の意図の伝達にマイナスに働きます。良きパートナーの関係を、利用者と供給者の関係に分類される三つの方法のどれかに変えることが現実的でしょう。"
11.6 システムの成長
【Page：211】
"システムの成長は、ソフトウェアが健全である証（あかし）です。機能の追加が続くのは、システムがうまくいっている証拠です。そのシステムは利用者に価値を提供し、さらなる要求に応え、競合プロダクトと対抗できています。しかしソフトウェアの成長は、よいことばかりではありません。開発規模が大きくなるにつれ、そのソフトウェアは大きな泥団子になってしまうかもしれません。
大きな泥団子は、その場しのぎの設計で、だらしなく、いいかげんで、つぎはぎだらけになったスパゲティコードのジャングルです。無秩序に機能を追加し、手っ取り早いやり方で修正を繰り返してきたことの、何よりの証拠です。
ーーブライアン・フートとジョセフ・ヨーダー
システムが無秩序に成長し、大きな泥団子になってしまうのは、機能を拡張する時に設計を再検討していないからです。成長することで、コンポーネントの境界が膨張し、ますます機能がそこに追加されます。"
１２章 イベントストーミング
12.1 イベントストーミングとは何か
【Page：217】
"イベントストーミングとは、業務プロセスのモデルを迅速に作ることを目的に、関係者が集まって、ブレインストーミングスタイルで進めるローテクな手法です。ある意味で、イベントストーミングは、業務知識を共有するための戦術的なツールと言えるでしょう。イベントストーミングをやる時は、最初に、モデルの対象とする範囲、つまり探求する業務プロセスを決めます。参加者は付箋を使って、業務の進行過程で発生する一連の業務イベントを時系列に並べながら、対象としている業務プロセスを探求します。そして、アクター、コマンド、外部システムなどの要素を少しずつ追加しながらモデルを拡張します。業務プロセスの仕組みを説明できるところまで要素がそろったら、イベントストーミングは終了です。"
12.1 イベントストーミングをいつ使うか
【Page：229】
"イベントストーミングは、次のように、さまざまな目的で実施できます。
- 同じ言葉の構築
- 業務プロセスのモデル化
- 新しい業務要件の探求
- 失われた業務知識の修復
- 既存の業務プロセスの改善方法を探る
- 新しいチームメンバーへのガイダンス
イベントストーミングをいつ使うかに加え、いつ使ってはいけないかも、重要なことなので、ここで触れておきます。イベントストーミングは、探求する業務プロセスが単純だったり明白だったりする場合には、うまくいかないでしょう。たとえば、流れ作業のように、興味をひくような業務ロジックや複雑さを伴わない領域です。
１３章 現実世界のドメイン駆動設計
【Page：235】
"
チーム全員がドメイン駆動設計を熟知し、最初から全員が役に立つモデルの探求に全力をつくし、当然のことながら、全員が同じ言葉を忠実に使っています。プロジェクトが進むにつれ、区切られた文脈の境界が明確になり、その境界は事業活動のさまざまなモデルをしっかりと保護しています。事業戦略と整合した実装方法が選択され、コードベースは体系的に整理されています。つまり、ソースコードが同じ言葉を語り、モデルの複雑さをうまく扱うための技法があちこちにちりばめられています。
残念ながら、これは夢物語です。目を覚ましましょう。
こういう理想的な状況でドメイン駆動設計に取り組めるとしたら、それは宝くじに当たったようなものです。もちろん、そういう可能性はゼロではありません。しかし現実には難しいでしょう。残念なことですが、多くの人は、ドメイン駆動設計を適用できるのは、新規の開発案件でドメイン駆動設計に熟達したメンバーがそろっている場合、という理想的な条件を満たしていることが必要だと誤解しています。皮肉なことに、ドメイン駆動設計が大きな効果をもたらすのは、すでに稼働しているソフトウェアに取り組んだ場合です。つまり、事業への貢献が実証されていて、積み重なった技術的負債と膨れ上がった設計の乱雑さを刷新する必要があるシステムこそ、ドメイン駆動設計で取り組む価値がもっとも高いのです。偶然にも、多くの技術者が取り組んでいるのは、このような、変更がやっかいで危険な大きな泥団子のコードベースです。
ドメイン駆動設計についてありがちな誤解に「すべてかゼロか」に二極化思考があります。ドメイン駆動設計のすべての技法を使うことがドメイン駆動設計であり、一部の技法だけを使うのはドメイン駆動設計ではない、というとらえ方です。そんなことはありません。ドメイン駆動設計のあらゆる側面を理解することは簡単なことではありません。ましてや、すべての技法を習得して実践することは、おそらく不可能でしょう。幸運なことに、すべての技法を取り入れなくても、ドメイン駆動設計は価値を生み出します。このことは、ドメイン駆動設計を既存システムに適用する場合は特に重要です。既存システムの修正や拡張に取り組んでいる場合、限られた時間の中であらゆる技法を取り入れることは不可能です。"
13.2 設計改善の基本方針
【Page：239】
"この機会に「システム全体を一から書き直し、すべての設計とコードをきれいにしよう」という挑戦が成功することは、ほとんどないでしょう。そして、そういう技術視点のシステム再構築を経営陣が支持することは、まずありえません。
既存システムの設計を改善する安全なやり方は、「大きな絵」を描き、「小さく始める」ことです。エリック・エヴァンスが書いているように、大規模なシステムのすべてをうまく設計することはできません。それが現実です。ですから、どこを重点的に改善するかを戦略的に判断しなければなりません。この戦略的判断の準備として、システムを複数の業務領域に切り分けます。その境界は、コードベースを物理的に分割するような、本格的な区切られた文脈である必要はありません。そうではなく、論理的な境界（名前空間、モジュール、パッケージなど）と業務領域の境界を対応させるところから始めます。"
第Ⅳ部 他の方法論や設計技法との関係
１４章 マイクロサービス
14.3.3 業務領域
【Page：268】
"マイクロサービスを設計する経験則として、区切られた文脈や集約よりもバランスがとれているのは、サービスの境界を業務領域に合わせる方法です。第１章で学んだように、業務領域は、細分化された事業活動であり、さまざまな業務活動が相互に連動します。業務領域は、企業が競合他社と競争するために必要となる、事業活動の構成要素です。事業活動の観点では、業務領域は事業が提供するサービス、つまり事業として何をするのかを説明するものであり、サービスをどのように実現するかは説明しません。技術的な観点では、業務領域は強い関連性を持った一貫したユースケースの集合です。つまり、事業活動の同じモデルを使い、同じデータもしくは密接に関連するデータを処理し、機能的に強く関係します。
（中略）
多くの場合、ユースケースの集合を小さな単位に分割すると、公開インターフェースが複雑になり、モジュールとしては浅くなります。これらの理由から、業務領域に合わせてマイクロサービスの境界を設計することは、安全な選択肢です。
マイクロサービスの境界を業務領域に合わせることが無難な経験則です。ほとんどのマイクロサービスによってはそれが最適解です。"
１５章 イベント駆動型アーキテクチャ
15.1 イベント駆動型アーキテクチャとは？
【Page：276】
"簡単に言えば、イベント駆動型アーキテクチャとは、システムのコンポーネント間で、イベントメッセージを非同期でやりとりする技術方式です。他のコンポーネントのエンドポイントを同期式で呼び出すのではなく、コンポーネントは、業務領域で何か変化が起きたことを他のコンポーネントに通知するために、イベントを発行（publish）します。他のコンポーネントはシステムで起きた変化をイベントとして購読（subscribe）し、そのイベントに応じた動作をします。第９章で説明したサーガは、典型的なイベント駆動型アーキテクチャです。
イベント駆動型アーキテクチャとイベントソーシングの違いをはっきりさせておきましょう。第７章で検討したように、イベントソーシングは、状態の変化を一連のイベントとして補足する方法です。
イベント駆動型アーキテクチャとイベントソーシングは、どちらもイベント（出来事）に注目します。しかし、二つの方式は異なる考え方です。イベント駆動型アーキテクチャはサービス間の通信方法です。一方で、イベントソーシングはサービス内部の実装方法です。イベントソーシングのイベントは、サービスの内部状態の変化（イベント履歴式ドメインモデルの集約の状態の変化）を表現します。イベントソーシングは事業活動の複雑さを把握するための方法です。システムの他のコンポーネントと連係することを意図した方法ではありません。"
15.2 イベント、コマンド、メッセージ
【Page：277】
"イベントはメッセージの定義と似ています。しかしこの二つは同じではありません。イベントはメッセージです。しかし、メッセージの種類はイベントだけではありません。メッセージは、イベントとコマンドの二つに分類できます。
- イベント：すでに起こった変化を表現したメッセージ
- コマンド：これから実行すべき操作を表現したメッセージ
イベントは過去に起きた何かです。それに対しコマンドはこれからやるべき何かを示します。イベントとコマンドのどちらも非同期メッセージとして送信されます。"
15.3.6.1 最悪のケースを想定する
【Page：289】
"アンドルー・グローブが書いたようにパラノイア（病的な心配性）だけが生き残ります（邦訳『パラノイアだけが生き残る』日経BP社、2017年）。イベント駆動型システムを設計する時は、この考え方を指針にしてください。
- ネットワークはかならず遅延する
- サーバーはもっとも都合が悪い時に故障する
- イベントは順番通りには届かない
- イベントは重複する
そして忘れてはいけません。こういう障害が起きるのは、決まって休日が祝祭日です。
イベント駆動型アーキテクチャの「駆動」が意味するのは、システム全体が、メッセージが確実に届くということに依存しているということです。ですから「うまくいくだろう」という期待は捨ててください。何があっても、イベントが確実に届く仕組みを工夫してください。"
１６章 データメッシュ
16.1.2 特性テーブル
【Page：297】
"このように特性を高度に正規化する理由は、分析計システムでは柔軟な検索が必要だからです。この正規化が、業務系モデルと分析計モデルのもう一つの違いです。業務系モデルでは、業務的に必要な検索を特定できます。分析系モデルでは、必要な検索パターンを予測できません。分析担当者はさまざまなやり方でデータを検索します。将来どんな検索をするのかはわかりません。そのため、高度に正規化しておいて、検索、絞り込み、そして異なる特性をまたがる事実データのグルーピングを必要に応じて動的に行うことを支援します。"
16.2.2 データレイク
【Page：304】
"さらに言えば、データレイクはスキーマレスです。つまり、取り込むデータに対して構造的な制約がなく、データの品質が保証されません。そのため、データレイクのデータは、ある程度の規模になると、かなり乱雑な状態になります。データレイクは、情報の発生源からのデータの取り込みは簡単ですが、データの利用は難しくなります。あるいは、よく言われることですが、データのレイク（湖）がデータの「沼」になります。沼のようにカオスになったデータの意味を解釈し、価値のある分析データを抽出するデータサイエンティストのしごとは、桁違いに複雑になります。"
結びの言葉
【Page：313】
"ドメイン駆動設計の探求を追えるにあたり、本書の最初で引用した、次の言葉に立ち戻りたいと思います。
課題の合意なしに解決方針の話をしても無意味である。解決方針の合意なしに実現手段の話をしても無意味である。
ーーエフラット・ゴールドラット・アシュラグ
この言葉こそ、この本で探求してきたドメイン駆動設計の本質です。
最後に
【Page：319】
"最後に一言。同じ言葉をつかって開発できているか、いつも気にかけてください。疑わしい時はイベントストーミングをやってみましょう。幸運をお祈りします。"
