ドメイン駆動設計入門(成瀬允宣)

書籍情報

• 著者:成瀬允宣(著)
• 発行日:2020-02-13
• ISBN:9784798150727
• URL:https://www.shoeisha.co.jp/book/detail/9784798150727

書籍目次

• はじめに
• 謝辞
• 本書の対象読者
• 取り扱うC#特有の構文
• 本書のサンプル動作環境とサンプルプログラムについて
• Chapter 1 ドメイン駆動設計とは
  • 1.1 ドメイン駆動設計とは何か
  • 1.2 ドメインの知識に焦点をあてた設計手法
    • 1.2.1 ドメインモデルとはなにか
    • 1.2.2 知識をコードで表現するドメインオブジェクト
  • 1.3 本書解説事項と目指すゴール
    • COLUMN ドメイン駆動設計の実践を難しくするもの
  • 1.4 本書で解説するパターンについて
    • 1.4.1 知識を表現するパターン
    • 1.4.2 アプリケーションを実現するためのパターン
    • 1.4.3 知識を表現する、より発展的なパターン
    • COLUMN なぜいま、ドメイン駆動設計か
• Chapter 2 システム固有の値を表現する「値オブジェクト」
  • 2.1 値オブジェクトとは
  • 2.2 値の性質と値オブジェクトの実装
    • 2.2.1 不変である
    • COLUMN 不変のメリット
    • 2.2.2 交換が可能である
    • 2.2.3 等価性によって比較される
  • 2.3 値オブジェクトにする基準
  • 2.4 ふるまいをもった値オブジェクト
    • 2.4.1 定義されないからこそわかること
  • 2.5 値オブジェクトを採用するモチベーション
    • 2.5.1 表現力を増す
    • 2.5.2 不正な値を存在させない
    • 2.5.3 誤った代入を防ぐ
    • 2.5.4 ロジックの散在を防ぐ
  • 2.6 まとめ
• Chapter 3 ライフサイクルのあるオブジェクト「エンティティ」
  • 3.1 エンティティとは
  • 3.2 エンティティの性質について
    • 3.2.1 可変である
    • COLUMN セーフティネットとしての確認
    • 3.2.2 同じ属性であっても区別される
    • 3.2.3 同一性をもつ
  • 3.3 エンティティの判断基準としてのライフサイクルと連続性
  • 3.4 値オブジェクトとエンティティのどちらにもなりうるモデル
  • 3.5 ドメインオブジェクトを定義するメリット
    • 3.5.1 コードのドキュメント性が高まる
    • 3.5.2 ドメインにおける変更をコードに伝えやすくする
  • 3.6 まとめ
• Chapter 4 不自然さを解決する「ドメインサービス」
  • 4.1 サービスが指し示すもの
  • 4.2 ドメインサービスとは
    • 4.2.1 不自然なふるまいを確認する
    • 4.2.2 不自然さを解決するオブジェクト
  • 4.3 ドメインサービスの濫用が行き着く先
    • 4.3.1 可能な限りドメインサービスを避ける
  • 4.4 エンティティや値オブジェクトと共にユースケースを組み立てる
    • 4.4.1 ユーザーエンティティの確認
    • 4.4.2 ユーザー作成処理の実装
    • COLUMN ドメインサービスの基準
  • 4.5 物流システムに見るドメインサービスの例
    • 4.5.1 物流拠点のふるまいとして定義する
    • 4.5.2 輸送ドメインサービスを定義する
    • COLUMN ドメインサービスの命名規則
  • 4.6 まとめ
• Chapter 5 データにまつわる処理を分離する「リポジトリ」
  • 5.1 リポジトリとは
    • COLUMN リポジトリはドメインオブジェクトを際立たせる
  • 5.2 リポジトリの責務
  • 5.3 リポジトリのインターフェース
    • COLUMN nullの是非とOption型
  • 5.4 SQLを利用したリポジトリを作成する
  • 5.5 テストによる確認
    • 5.5.1 テストに必要な作業を確認する
    • 5.5.2 祈り信者のテスト理論
    • 5.5.3 祈りを捨てよう
  • 5.6 テスト用のリポジトリを作成する
  • 5.7 オブジェクトリレーショナルマッパーを用いたリポジトリを作成する
  • 5.8 リポジトリに定義されるふるまい
    • 5.8.1 永続化に関するふるまい
    • 5.8.2 再構築に関するふるまい
  • 5.9 まとめ
• Chapter 6 ユースケースを実現する「アプリケーションサービス」
  • 6.1 アプリケーションサービスとは
    • COLUMN アプリケーションサービスという名前
  • 6.2 ユースケースを組み立てる
    • 6.2.1 ドメインオブジェクトから準備する
    • 6.2.2 ユーザ登録処理を作成する
    • 6.2.3 ユーザ情報取得処理を作成する
    • COLUMN 煩わしさを減らすために
    • 6.2.4 ユーザ情報更新処理を作成する
    • COLUMN エラーかそれとも例外か
    • 6.2.5 退会処理を作成する
  • 6.3 ドメインのルールの流出
  • 6.4 アプリケーションサービスと凝集度
    • 6.4.1 凝集度が低いアプリケーションサービス
  • 6.5 アプリケーションサービスのインターフェース
  • 6.6 サービスとは何か
    • 6.6.1 サービスは状態をもたない
  • 6.7 まとめ
• Chapter 7 柔軟性をもたらす依存関係のコントロール
  • 7.1 技術要素への依存がもたらすもの
  • 7.2 依存とは
  • 7.3 依存関係逆転の原則とは
    • 7.3.1 抽象に依存せよ
    • 7.3.2 主導権を抽象に
  • 7.4 依存関係をコントロールする
    • 7.4.1 Service Locatorパターン
    • 7.4.2 IoC Containerパターン
  • 7.5 まとめ
• Chapter 8 ソフトウェアシステムを組み立てる
  • 8.1 ソフトウェアに求められるユーザーインターフェース
    • COLUMN ソフトウェアとアプリケーションの使い分け
  • 8.2 コマンドラインインターフェースに組み込んでみよう
    • COLUMN シングルトンパターンと誤解
    • 8.2.1 メインの処理を実装する
  • 8.3 MVCフレームワークに組み込んでみよう
    • COLUMN コントローラの責務
    • 8.3.1 依存関係を設定する
    • 8.3.2 コントローラを実装する
  • 8.4 ユニットテストを書こう
    • 8.4.1 ユーザー登録処理のユニットテスト
  • 8.5 まとめ
    • COLUMN 本当に稀な怪談話
• Chapter 9 複雑な生成処理を行う「ファクトリ」
  • 9.1 ファクトリの目的
  • 9.2 採番処理をファクトリに実装した例の確認
    • COLUMN ファクトリの存在に気づかせる
    • 9.2.1 自動採番機能の活用
    • 9.2.2 リポジトリに採番用メソッドを用意する
  • 9.3 ファクトリとして機能するメソッド
  • 9.4 複雑な生成処理をカプセル化しよう
    • COLUMN ドメイン設計を完成させるために必要な要素
  • 9.5 まとめ
• Chapter 10 データの整合性を保つ
  • 10.1 整合性とは
  • 10.2 致命的な不具合を確認する
  • 10.3 ユニークキー制約による防衛
    • 10.3.1 ユニーク制約を重複確認の主体としたときの問題点
    • 10.3.2 ユニークキー制約との付き合い方
  • 10.4 トランザクションによる防衛
    • 10.4.1 トランザクションによる防衛
    • 10.4.2 トランザクションスコープを利用したパターン
    • 10.4.3 AOPを利用したパターン
    • 10.4.4 ユニットオブワークを利用したパターン
    • COLUMN 結局どれを使うべきか
    • 10.4.5 トランザクションが引き起こすロックについて
  • 10.5 まとめ
• Chapter 11 アプリケーションを1から組み立てる
  • 11.1 アプリケーションを組み立てるフロー
  • 11.2 題材とする機能
    • 11.2.1 サークル機能の分析
  • 11.3 サークルの知識やルールをオブジェクトとして準備する
  • 11.4 ユースケースを組み立てる
    • 11.4.1 言葉との齟齬が引き起こす事態
    • 11.4.2 漏れ出したルールがもたらすもの
  • 11.5 まとめ
• Chapter 12 ドメインのルールを守る「集約」
  • 12.1 集約とは
    • 12.1.1 集約の基本的構造
    • COLUMN 集約を保持するコレクションを図に表すか
    • 12.1.2 オブジェクトの操作に関する基本的な原則
    • 12.1.3 内部データを隠蔽するために
    • COLUMN よりきめ細やかなアクセス修飾子（Scala）
  • 12.2 集約をどう区切るか
    • 12.2.1 IDによるコンポジション
    • COLUMN IDのゲッターに対する是非
  • 12.3 集約の大きさと操作の単位
    • COLUMN 結果整合性
  • 12.4 言葉との齟齬を消す
  • 12.5 まとめ
• Chapter 13 複雑な条件を表現する「仕様」
  • 13.1 仕様とは
    • 13.1.1 複雑な評価処理を確認する
    • 13.1.2 「仕様」による解決
    • 13.1.3 リポジトリの使用を避ける
  • 13.2 仕様とリポジトリを組み合わせる
    • 13.2.1 お勧めサークルに見る複雑な検索処理
    • 13.2.2 仕様による解決法
    • 13.2.3 仕様とリポジトリが織りなすパフォーマンス問題
    • 13.2.4 複雑なクエリは「リードモデル」で
    • COLUMN 遅延実行による最適化
  • 13.3 まとめ
• Chapter 14 アーキテクチャ
  • 14.1 アーキテクチャの役目
    • 14.1.1 アンチパターン:利口なUI
    • 14.1.2 ドメイン駆動設計がアーキテクチャに求めること
  • 14.2 アーキテクチャの解説
    • 14.2.1 レイヤードアーキテクチャとは
    • 14.2.2 ヘキサゴナルアーキテクチャとは
    • 14.2.3 クリーンアーキテクチャとは
  • 14.3 まとめ
• Chapter 15 ドメイン駆動設計のとびらを開こう
  • 15.1 軽量DDDに陥らないために
    • COLUMN パターンの濫用とパターンを捨てるとき
  • 15.2 ドメインエキスパートとモデリングをする
    • 15.2.1 本当に解決すべきものを見つけよう
    • 15.2.2 ドメインとコードを結びつけるモデル
  • 15.3 ユビキタス言語
    • 15.3.1 深い洞察を得るために
    • 15.3.2 ユビキタス言語がコードの表現として使われる
    • COLUMN ユビキタス言語と日本語の問題
  • 15.4 境界付けられたコンテキスト
  • 15.5 コンテキストマップ
    • 15.5.1 テストがチームの架け橋に
  • 15.6 ボトムアップドメイン駆動設計
  • 15.7 まとめ
• Appendix ソリューション構成
  • A.1 ソフトウェア開発の最初の一歩
    • COLUMN C#特有のプロジェクト管理用語
    • A.1.1 全てを別プロジェクトにする
    • A.1.2 アプリケーションレイヤーのパッケージ構成
    • A.1.3 インフラストラクチャレイヤーのパッケージ構成
  • A.2 ソリューション構成
    • A.2.1 すべてを別のプロジェクトにする
    • A.2.2 アプリケーションとドメインだけ同じプロジェクトにする
    • A.2.3 言語機能が与える影響
  • A.3 まとめ
• 参考文献
• INDEX