概要

エリック・エヴァンスのドメイン駆動設計: ソフトウェアの核心にある複雑さに立ち向かう

DDD本を輪読会で読み終わったので読書メモを残す。

序章

• ドメインモデルは”考え方”。知識の再構成と抽象化。表現手段（図でもプログラミング言語でも自然言語でも）は問わない。
• モデルの基本的用法
  • モデルと設計の核心が相互に形成し合う
  • モデルは、チームメンバ全員が使用する言語の基盤
  • モデルとは蒸留された知識
• ソフトウェアの核心≒ドメインに関係した問題をユーザーのために解決する能力

第1章知識をかみ砕く

• 効果的なモデリングの要素
  • モデルと実装の結合、モデルに基づいた言語の洗練、知識豊富なモデルの開発、モデルの蒸留、ブレストと実験の繰り返し
• モデルにはビジネスの深い知識が反映されている、その抽象がビジネスの真の原理
  • 知識の断片化を防ぐ、集団的な知識の蓄積、獲得
• ドメイン
  • 知識、影響、活動領域
• エンティティ
  • 本質的に属性ではなく、連続性と同一性の連なりによって定義されるオブジェクト

第2章コミュニケーションと言語の使い方

• ドメインモデル
  • プロジェクトにおける共通言語のコアとなることができる
    • 言語の使い方は重要
• ユビキタス言語
  • ドメインモデルを元に構築され、チームの活動をソフトウェアと結びつける、チームメンバ全員によって使用される言語
  • ユビキタス言語における変更は、モデルに対する変更ともなる
  • ユビキタス言語は、設計にはあるが、コードに表現されない側面を伝えるための主な手段
• ドキュメントはコードや会話での表現を補う必要がある
  • コードがうまくやっていることをドキュメントでもやろうとする必要はない
  • ドキュメントは役に立つものであること、常に最新を保つこと、プロジェクトの活動に取り込まれていること

第3章モデルと実装を結びつける

• 分析モデル
  • 設計者とは別の人々によって開発されるモデル。
  • ビジネスドメインの分析結果であり、ソフトウェアで果たす役割が考慮されていない概念のまとめ上げ。
• 設計または設計の中心となる部分がドメインモデルに紐付いていない場合は、モデルに価値はない。ソフトウェアも不正確。
• モデルと設計された機能との紐付けが複雑だと設計が変更された時に紐付けの維持が難しくなり、分析と設計に亀裂が生じる
• モデル駆動設計
  • 分析と設計の両方に使える単一のモデルを探す行為
• オブジェクト指向プログラミング
  • モデルを構成する概念に実装を提供

第4章ドメインを隔離する

• レイヤー化アーキテクチャ
  • 各レイヤで設計を進め、凝集度を高めて下位層だけに依存するようにすること
  • 上位のレイヤに対しては疎結合にすること
• 利口なUI
  • ビジネスロジックやデータアクセスなどがUIに結びついてしまっている形
  • モデル駆動設計を妨げる

第5章ソフトウェアで表現されたモデル

• 多対多の関連
  • 限定子が一対一の関連に減らす
• 多くのオブジェクトは本質的に、その属性ではなく、連続性と同一性によって定義される
  • 同一性は時間が経っても異なる形で表現されても変わらない（≒普遍性を伴う？）
• エンティティ
  • 同一性によって定義されるオブジェクト
• 値オブジェクト
  • ドメインにおける記述的な側面を表現し、概念的な同一性を持たないオブジェクト
• サービス
  • モデルにおいて、独立したインターフェースとして提供される
  • エンティティや値オブジェクトのように状態をカプセル化しない
  • ユビキタス言語の一部になるように操作名をつける
  • サービスには状態を持たせない
• モジュール
  • パッケージとか名前空間とかのプログラミングの仕組み？

第6章ドメインオブジェクトのライフサイクル

• オブジェクトのライフサイクル
  • 生成、格納、再構成、修正、削除
• オブジェクト管理の課題
  • 課題カテゴリ
    • ライフサイクルを通じて整合性を維持すること
    • ライフサイクルを管理するのが複雑でも、モデルが侵食されないようにすること
  • →集約、リポジトリ、ファクトリで対応する
• 集約
  • 関連するオブジェクトの集まりであり、データを変更するための単位
• ファクトリ
  • クライアント側に生成を任せるとクライアント側の設計を混乱させてしまうので、生成側で組み立てのロジックを持つ
  • ファクトリの設計方法
    • ファクトリメソッド、抽象ファクトリ、ビルダー
• リポジトリ
  • 特定の方のオブジェクトを全て概念上の集合として表現

第7章 言語を使用する：応用例

N/A

第8章ブレイクスルー

• 深いモデルは表面的な側面を捨て去ってしまう
  • 深いモデルはドメインエキスパートの関心事とそれに関連した知識についての明快な表現する
  • 抽象的な要素を持つが、問題の核心迫る部分には具体的な要素もある
• モデルの探求の先にブレイクスルーがある
• ブレイクスルーを意図的に起こそうとしてはいけない。リファクタの繰り返しの先にモデルについての洞察が深まり、引き起こされる。
• ブレイクスルーの結果、ユビキタス言語が刷新されてコミュニケーションが改善、さらなるモデリングのブレイクスルーにつながる

第9章暗黙的な概念を明示的にする

• 概念を掘り出す
  • 言葉に耳を傾ける
  • ぎこちなさ（説明しづらい部分や複雑さが増している部分）を精査する
  • 矛盾について熟考する
  • 文献を読む
  • 何度でも挑戦すること
• それほど明白でない概念をモデル化する方法
  • 明示的な制約（設計を明示する）
  • ドメインオブジェクトとしてのプロセス
    • ドメインに存在するプロセスはモデルの中に表現する
• 仕様
  • 特殊な目的の値オブジェクト。
  • cf.
    • https://nocturne-life-restoration.hatenablog.com/entry/2015/06/04/062151
    • https://bamboo-yujiro.hatenablog.com/entry/2020/03/21/215005
    • https://www.ogis-ri.co.jp/otc/hiroba/technical/DDDEssence/chap2.html

第10章しなやかな設計

• しなやかな設計
  • 楽しく仕事ができて変更を呼び込むような設計
  • 深いモデリングを補完する
• 意図の明白なインターフェース
  • ユビキタス言語に従って命名
• 副作用のない関数
  • 意図しない影響が発生しない関数。複雑さを取り払う
• 表明
  • 条件を明記する。不変条件も定義する。暗黙を避ける。
• 概念の輪郭 -意味のある単位で設計要素（操作、インターフェース、クラス、集約）を分解する
• 独立したクラス
  • 低結合なオブジェクト設計
  • 本質的な依存関係を取り除く
• 閉じた操作
  • 戻り値の型が引数の型と同じにできる場合はそのように定義する→閉じた操作とんある

第11章アナリシスパターンを適用する

• アナリシスパターン
  • ビジネスモデリングにおける共通の構造を表す、概念のグループ。1つ以上のドメインに適す。

第12章 デザインパターンをモデルに関係づける

• ストラテジー（ポリシー）パターン
  • ドメインパターンとしては、プロセスやポリシーといったルールなどの概念を表現する部分に着目
• コンポジットパターン
  • ドメインパターンとしては、構成する全てのメンバを包括的に含む抽象型を定義すること

第13章より深い洞察へ向かうリファクタリング

• 直前5章分の振り返り
• 変更を完全に正当化できるまで待つのは、待ちすぎというものである（至言）

第14章 モデルの整合性を維持する

• 境界づけられたコンテキスト
  • モデルを切り分けるのための境界定義。境界内→コンテキスト
• 継続的な統合
  • 境界づけられたコンテキスト内のコードと成果物を頻繁にマージさせる
• コンテキストマップ
  • コンテキストとコンテキストの関係性を定義づける
• 共有カーネル
  • コンテキストとコンテキストの接合点にある、共有されるモデルのことかな？？
• 顧客/供給者の開発チーム
  • 呼び出し元（上流）と呼び出す側（下流）の関係性
  • テストで連携しましょう
• 順応者
  • 下流は上流の要求の応えよう？？
• 腐敗防止層
  • 新システムとレガシーシステムとのやりとりをうまくやるための層。レガシーに引きづられないように隔離する
• 別々の道
  • モデルの統合は必ずしも吉、メリットが大きいとは限らない
• 公開ホストサービス
  • プロトコルの公開
• 公表された言語
  • 複数のコンテキストにまたがるユビキタス言語？？

第15章 蒸留

• 蒸留とは
  • 混ざりあったコンポーネントを分離するプロセス。本質を抽出する。

第16章 大規模な構造

• 大規模な構造
  • システムをおおよその構造から議論し、理解できるようにするための言語

第17章 戦略をまとめ上げる

N/A