Program設計ドメイン駆動設計

2020-09-07 (月) 公開
2020-09-09 (水) 更新

ドメイン駆動設計について学びましょう!

ドメイン駆動設計入門

 ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本
成瀬 允宣
翔泳社
2020-02-13
¥ 3,520

目次

 はじめに
 謝辞
 本書の対象読者
 取り扱う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フレームワークに組み込んでみよう
  8.3.1 依存関係を設定する
  8.3.2 コントローラを実装する
  COLUMN|コントローラの責務
 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

出版社情報

著者紹介

成瀬 允宣(ナルセ マサノブ)
岐阜県出身。プログラマ。プログラミングにはじめて触れたのは25 歳のとき。
業務システム開発からキャリアをはじめ、ゲーム、Web と業種を変えながらも
アプリケーション開発全般に従事。好きな原則はDRY原則。趣味は車輪の再開発。

書評



トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2020-09-07 (月) 16:52:59 (50d)