「『ドメイン駆動設計』のススメ - 100日でエヴァンス本を完読したしょぼちむとふりかえる」を視聴したので、その記録 - Qiita の通り。
DDD、エヴァンス本。すごい人が読むすごい本だと思っている。しょぼちむさんも事実すごいし素晴らしい。自分も謙虚に頑張りたい...
エヴァンス本、途中まで読んで、岩波文庫を読み始めてしまった学生時代を思い出した私
となってしまっていた私だが、気負わず一読くらいはしてみようと改めて思い直しまとめ直したものです。以下がとても参考になりました。
しょぼちむのエヴァンス本のススメ / syobochim read Evans Book - Speaker Deck
面白かった部ランキングより:
この理解に共感するとともに、「おう、これが噂の2部だよな...」と念頭に置きながら読むことで、2部を恐れずにすみました。自分の言葉でさらに表現するなら、村上春樹の小説よろしく抽象度が高くいかようにも解釈できそうに読めてしまうのが2部で、一読しただけでは「こういうこと？」「いやこういうことでもあるのかな？」など感じられる危険があります。
しかしその2部冒頭に書かれている通り「これからの3つの章の内容は、「パターンランゲージ」（付録参照）として構成されており、そこでは、モデルのわずかな違いと設計における意思決定が、ドメイン駆動設計のプロセスにどれほど影響を与えるかが示される」とのことで、そんな気持ちを持ちつつ読み進めてもいいのだなというのがまさしく第2部なのだと思います。
この他、読書に関するそもそも論は「まとめ」部に記載します。
目次: エリック・エヴァンスのドメイン駆動設計（牧野 祐子 牧野 祐子 今関 剛 今関 剛 今関 剛 和智 右桂 和智 右桂 Eric Evans）｜翔泳社の本
- 第1部 ドメインモデルを機能させる
- ドメイン駆動設計におけるモデルの有用性
- ソフトウェアの核心
- 第2部 モデル駆動設計の構成要素
- 第3部 より深い洞察へ向かうリファクタリング
- リファクタリングのレベル
- 深いモデル
- 深いモデル／しなやかな設計
- 発見のプロセス
- 第4部 戦略的設計
第1部 ドメインモデルを機能させる
- すべてのソフトウェアプログラムは、使用するユーザの何らかの活動や関心と関係がある。ユーザがプログラムを適用する対象領域が、ソフトウェアのドメインである。物理的な世界を含んでいるものもある。例えば、航空会社の予約プログラムのドメインは、実際の航空機に搭乗する現実の人々を含んでいる。
- 開発チームはその活動に関係する体系化された知識を身につけていかなければならない。ここで要求される知識の幅広さに手こずるかもしれないし、情報の量と複雑さに圧倒されるかもしれない。モデルはこの重荷と格闘するためのツールなのだ。
- ドメインモデルとは特定の図ではなく、図が伝えようとしている考え方である。これはドメインエキスパートの頭の中にある単なる知識ではなく、その知識が厳密に構成され、選び抜かれて抽象化されたものなのだ。
第1章 知識をかみ砕く
- 「モデルは、チームメンバ全員が使用する言語の基盤である」
- 「モデルとは、蒸留された知識である」
- 効果的なモデリングの要素
- モデルと実装を結びつける
- モデルに基づいて言語を洗練させる
- 知識豊富なモデルを開発する
- モデルを蒸留する
- ブレインストーミングと実験を行う
第2章 コミュニケーションと言語の使い方
- システムについて語る際には、モデルをいろいろと試してみること。モデルの要素と相互作用を使い、モデルに許された方法で概念を結びつけながら、シナリオを声に出して描写すること。表現すべきことをより簡単に言う方法を見つけ、その新しい考え方を図とコードに再び反映させること。
- 豊富な知識を持つドメインエキスパートがモデルを理解できないとしたら、モデルに何か問題があるのだ。
- すでにコードがうまくやっていることを、ドキュメントでもやろうとするべきではない。
- ドキュメントは活動の役に立たなければならず、最新の状態を保たなければならない。
- ドキュメントを最小限に留め、その焦点をコードと会話の補足に絞ることで、ドキュメントがプロジェクトに結びつけられた状態を保つことができる。ユビキタス言語とその進化を指針として、プロジェクトの活動に織り込まれる生きたドキュメントを選び出すこと。
第3章 モデルと実装を結びつける
- コードをその元になっているモデルへ緊密に関係づけることにより、コードに意味が与えられ、モデルがドメインと関連の深いものになる。
- 設計が、あるいは設計の中心となる部分が、ドメインモデルに紐づいていないならば、そのモデルにほとんど価値はなく、ソフトウェアが正確であるかどうかも疑わしい。同じように、モデルと設計された機能との紐づけが複雑だと理解するのが難しく、実際には、設計が変更された時に紐づけを維持できなくなる。分析と設計の間に致命的な亀裂が生じるため、それぞれの作業で得られる洞察は互いに活かされることがない。
第2部 モデル駆動設計の構成要素
- ソフトウェアの実装を単純明快なものにしつつ、モデルと歩調の合った状態に保つためには、たとえ現実がひどいものでも、モデリングと設計のベストプラクティスを適用しなければならない。
- これからの3つの章の内容は、「パターンランゲージ」（付録参照）として構成されており、そこでは、モデルのわずかな違いと設計における意思決定が、ドメイン駆動設計のプロセスにどれほど影響を与えるかが示される。
第4章 ドメインを隔離する
- レイヤ化アーキテクチャ（LAYERED ARCHITECTURE）
- ユーザインタフェース（またはプレゼンテーション層）
- アプリケーション層
- ドメイン層（またはモデル層）
- インフラストラクチャ層
- DDD本4章を読んでこのように理解しました - Qiita
第5章 ソフトウェアで表現されたモデル
- 「関連」
- 関連の数を根本的に小さくする必要がある
- 関連の方向を強制する（一方向にする）
- 限定子をつけて多重度を減らす
- たとえば国はnの大統領を持てるが、「期間」で限定すれば1人しか持てない（ある時点には1人しかいないはず）
- モデリングパラダイム
- なぜオブジェクトパラダイムが主流なのか？
- 開発者コミュニティと設計文化そのものの成熟
- オブジェクトの世界におけるオブジェクトではないもの
- パラダイムを混在させる際にはモデル駆動設計に忠実であること
- DDD本5章を読んでこのように理解しました - Qiita
- なぜオブジェクトパラダイムが主流なのか？
第6章 ドメインオブジェクトのライフサイクル
- 集約（AGGREGATES）
- ファクトリ（FACTORIES）
- リポジトリ（REPOSITORIES）
- 関係データベースに合わせてオブジェクトを設計する
第7章 言語を使用する：応用例
- 貨物輸送システムを導入する
- ドメインを隔離する：アプリケーションの導入
- エンティティと値オブジェクトを区別する
- 輸送ドメインの関連を設計する
- 集約の境界
- リポジトリを選択する
- シナリオをウォークスルーする
- オブジェクトの生成
- リファクタリングのために立ち止まる：貨物集約についてのもう1つの設計
- 輸送モデルにおけるモジュール
- 新機能を導入する：配分チェック
第3部 より深い洞察へ向かうリファクタリング
- 深いモデルは、ドメインエキスパートの主要な関心事と、それに最も深く関連した知識に関する明快な表現を提供するが、一方で、ドメインの表面的な側面は捨て去るのだ。
第8章 ブレイクスルー
- ブレイクスルーの舞台を整えるためには、知識をかみ砕き、強固なユビキタス言語を育成するのに集中すること。重要なドメインの概念を探究して、それをモデルで明示すること（第9 章で議論する）。設計をよりしなやかになるように改良すること（第10 章参照）。モデルを蒸留すること（第15 章参照）。
第9章 暗黙的な概念を明示的にする
- 特殊な目的を持った述語的な値オブジェクトを明示的に作成すること。仕様とは、あるオブジェクトが何らかの基準を満たしているかどうかを判定する述語である。
- ドメイン駆動設計の用語と解説(抜粋版) - Qiita
第10章 しなやかな設計
- ソフトウェアの最終目的はユーザの役に立つこと。しかしそれ以前にソフトウェアは開発者の役に立たなければならない。このことはリファクタリングを重視するプロセスに特に当てはまる。プログラムが進化するにつれ開発者はあらゆる部分を再配置し書き直す
- 設計が明確でないと開発者は混乱した状態に目を向けることも恐れ、変更を加えるなどもってのほかと考えるようになる。予期せぬ依存関係のせいでもつれを悪化させたり何かを壊したりするかもしれないからだ。最小のシステムでない限り脆弱なせいで構築できるふるまいの豊かさに限界ができてしまう
- 開発の進行に合わせてプロジェクトを加速させるためには、楽しく仕事ができて変更を呼び込むような設計が欠かせない。それがしなやかな設計である。
- 初期バージョンはたいてい固い。納期や予算のせいでしなやかになることがない。巨大なプログラムが徹底してしなやかに作られているのを見たことがない。しかし複雑さによって阻まれているなら重大で難解な部分をしなやかな設計にすればレガシーの保守に飲み込まれることなく複雑さの限界を破れる
- ある開発者があるコンポーネントを使用するために、その実装についてじっくり考えなければならないのであれば、カプセル化の価値は失われる。
- クラスと操作にはその効果と目的を記述する名前をつけ約束したことを実行する手段には言及しない。こうした名前はユビキタス言語に従っていなければならない
- 普通の言葉で副作用（side effect）と言えば、意図しない結果を意味するが、コンピュータ科学では、システムの状態に対して与えられる、あらゆる影響を意味する。
第11章 アナリシスパターンを適用する
- 深いモデルとしなやかな設計は、容易に手に入るものではない。こうしたモデルや設計を発展させるためには、ドメインについて大いに学び、多くの話し合いと試行錯誤を重ねる必要がある。もっとも、時にはよいスタートが切れることもある。
- アナリシスパターンは活用すべき知識である
第12章 デザインパターンをモデルに関係づける
- ストラテジー（STRATEGY）（別名 ポリシー（POLICY））
- コンポジット（COMPOSITE）
- ちょっとずつ読むドメイン駆動設計 第三部 より深い洞察へ向かうリファクタリング 第十ニ章 デザインパターンをモデルに関係づける - Qiita
第13章 より深い洞察へ向かうリファクタリング
- ドメインに馴染む。
- 常に、物事に対して違う見方をする。
- ドメインエキスパートとの対話を途切れさせない。
第4部 戦略的設計
- 第4部では広い範囲にわたる3 つのテーマを考察する。それが、コンテキスト、蒸留、大規模な構造である。
第14章 モデルの整合性を維持する
第15章 蒸留
- ドメインモデルに対する戦略的蒸留
- システムの全体的な設計と、設計同士がどう関係するのかを、チームメンバ全員が把握できるようにする。
- ユビキタス言語に入れやすいサイズのコアモデルを識別することで、コミュニケーションを促進する。
- リファクタリングの指針となる。
- モデルで最も価値がある領域に作業を集中させる。
- アウトソーシングと既製のコンポーネントの利用、その割り当てについて決定する際の指針となる。
- 現実は厳しいもので、設計のすべての部分が等しく改良されるわけではない。優先順位を設定しなければならないのだ。ドメインモデルを資産化するには、モデルのきわめて重要なコアを洗練し、アプリケーションの機能を作り出す上で最大限に活用しなければならない。
- 反面、高いスキルを持った開発者はそう多くいないが、そういう開発者が魅かれがちなのは、技術的なインフラストラクチャや、特別なドメインの知識がなくても理解可能な、うまく限定できるドメインに関する問題なのである。
- モデルを煮詰めること。コアドメインを見つけて、それをサポートする大量のモデルやコードから容易に区別する手段を提供すること。最も価値のある特化した概念を浮き彫りにすること。コアは小さくすること。最も才能がある人をコアドメインに割り当て、そうした区分に応じて採用すること。コアに対して力を尽くし、深いモデルを見つけ出し、システムのビジョンを実現するのに十分な、しなやかな設計を開発すること。
第16章 大規模な構造、第17章 戦略をまとめ上げる
その他参考
エリック・エヴァンスのドメイン駆動設計_読書メモ
「『ドメイン駆動設計』のススメ - 100日でエヴァンス本を完読したしょぼちむとふりかえる」を視聴したので、その記録 - Qiita
エヴァンス本も読まずにドメイン駆動設計とは何事か？
ドメイン駆動設計にまつわる概念
まとめ
- 私の考える本の読み方
- 本はまず目次から作られるから目次で面白そうなところにアタリをつける。
- 本の構成もパターンがありストーリーがよほどあるもの以外辞書的だったりカテゴリ、階層別だったりするからそれを読み解いた上で読みたいところからまず読むもアリ。
- ということで、このエヴァンス本も例に漏れない。
- キーフレーズを太字で書いてくれているのが最低限度の、親切設計であるなとは思う。
- あと、やはり、本は読んでなんぼ。
という点でこんな薄っすらとでも一読したので、読書したい人の後押しになればとおもう。以上です～