【DDD】ドメイン駆動設計【エリック・エヴァンス】

**デフォルトの名無しさん** · 2017/10/24(火) 19:39:06.49

第1部　ドメインモデルを機能させる

　　　ドメイン駆動設計におけるモデルの有用性
　　　ソフトウェアの核心

第1章知識をかみ砕く
　　　効果的なモデリングの要素
　　　知識のかみ砕き
　　　継続的学習
　　　知識豊富な設計
　　　　　　例1.1——隠された概念を引き出す
　　　深いモデル

第2章コミュニケーションと言語の使い方
　　　ユビキタス言語（UBIQUITOUS LANGUAGE）
　　　　　　例2.1——貨物輸送プログラムを完成させる
　　　声に出してモデリングする
　　　1つのチームに1つの言語
　　　ドキュメントと図
　　　　　　書かれた設計ドキュメント
　　　　　　実行可能な基盤
　　　説明のためのモデル
　　　　　　例2.2——輸送業務と経路

第3章モデルと実装を結びつける
　　　モデル駆動設計（MODEL-DRIVEN DESIGN）
　　　モデリングパラダイムとツールによるサポート
　　　　　　例3.1——手続き型からモデル駆動へ
　　　骨格を見せる：なぜモデルがユーザにとって重要なのか？
　　　実践的モデラ（HANDS ON MODELERS）

**デフォルトの名無しさん** · 2017/10/24(火) 19:40:39.31

>>1
いきなり目次って
ここ読書スレ？

**デフォルトの名無しさん** · 2017/10/24(火) 19:40:53.73

第2部　モデル駆動設計の構成要素

第4章ドメインを隔離する
　　　レイヤ化アーキテクチャ（LAYERED ARCHITECTURE）
　　　　　　例4.1——オンラインバンキングの機能をレイヤに分割する
　　　　　　レイヤを関係づける
　　　　　　アーキテクチャフレームワーク
　　　ドメイン層はモデルが息づく場所
　　　利口なUI「アンチパターン」（SMART UI ﾒANTI-PATTERNﾓ）
　　　その他の隔離

**デフォルトの名無しさん** · 2017/10/24(火) 19:41:31.02

第5章ソフトウェアで表現されたモデル
　　　関連
　　　　　　例5.1——証券取引口座における関連
　　　エンティティ（ENTITIES）（別名　参照オブジェクト（REFERENCE OBJECTS））
　　　　　　エンティティをモデル化する
　　　　　　同一性のための操作を設計する
　　　値オブジェクト（VALUE OBJECTS）
　　　　　　値オブジェクトを設計する
　　　　　　例5.2——値オブジェクトを使ってデータベースをチューニングする
　　　　　　値オブジェクトを含む関連を設計する
　　　サービス（SERVICES）
　　　　　　サービスと隔離されたドメイン層
　　　　　　粒度
　　　　　　サービスへのアクセス
　　　モジュール（MODULES）（別名　パッケージ（PACKAGES））
　　　　　　アジャイルモジュール
　　　　　　例5.3——Javaにおけるパッケージのコーディング規約
　　　　　　インフラストラクチャ駆動パッケージングの落とし穴
　　　モデリングパラダイム
　　　　　　なぜオブジェクトパラダイムが主流なのか？
　　　　　　オブジェクトの世界におけるオブジェクトではないもの
　　　　　　パラダイムを混在させる際にはモデル駆動設計に忠実であること

**デフォルトの名無しさん** · 2017/10/24(火) 19:42:12.50

第6章ドメインオブジェクトのライフサイクル
　　　集約（AGGREGATES）
　　　　　　例6.1——購入注文の整合性
　　　ファクトリ（FACTORIES）
　　　　　　ファクトリとその場所を選択する
　　　　　　コンストラクタがあればよい場合
　　　　　　インタフェースを設計する
　　　　　　不変条件のロジックはどこへ置くべきか？
　　　　　　エンティティファクトリ対値オブジェクトファクトリ
　　　　　　格納したオブジェクトを再構成する
　　　リポジトリ（REPOSITORIES）
　　　　　　リポジトリに対して問い合わせる
　　　　　　クライアントのコードはリポジトリの実装を無視するが、開発者はそうではない
　　　　　　リポジトリを実装する
　　　　　　フレームワークの範囲内で作業する
　　　　　　ファクトリとの関係
　　　関係データベースに合わせてオブジェクトを設計する

**デフォルトの名無しさん** · 2017/10/24(火) 19:42:47.43

第7章言語を使用する：応用例
　　　貨物輸送システムを導入する
　　　ドメインを隔離する：アプリケーションの導入
　　　エンティティと値オブジェクトを区別する
　　　　　　役割とその他の属性
　　　輸送ドメインの関連を設計する
　　　集約の境界
　　　リポジトリを選択する
　　　シナリオをウォークスルーする
　　　　　　サンプルアプリケーションの機能：貨物の荷出し地を変更する
　　　　　　サンプルアプリケーションの機能：リピータへの対応
　　　オブジェクトの生成
　　　　　　貨物用のファクトリとコンストラクタ
　　　　　　荷役イベントを追加する
　　　リファクタリングのために立ち止まる：貨物集約についてのもう1つの設計
　　　輸送モデルにおけるモジュール
　　　新機能を導入する：配分チェック
　　　　　　2つのシステムを接続する
　　　　　　モデルを強化する：ビジネスのセグメント化
　　　　　　パフォーマンスチューニング
　　　最後に

**デフォルトの名無しさん** · 2017/10/24(火) 19:43:20.05

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

　　　リファクタリングのレベル
　　　深いモデル
　　　深いモデル／しなやかな設計
　　　発見のプロセス

第8章ブレイクスルー
　　　ブレイクスルーの話
　　　　　　悪くないモデルなのだが…
　　　　　　ブレイクスルー
　　　　　　さらに深いモデル
　　　　　　冷静な意思決定
　　　　　　結末
　　　好機
　　　基本への集中
　　　エピローグ：新しい洞察の連鎖

**デフォルトの名無しさん** · 2017/10/24(火) 19:43:49.53

第9章暗黙的な概念を明示的にする
　　　概念を掘り出す
　　　　　　言葉に耳を傾ける
　　　　　　例9.1——輸送モデルに欠けている概念を聞き分ける
　　　　　　ぎこちなさを精査する
　　　　　　例9.2——利息を得る　難しい方法
　　　　　　矛盾について熟考する
　　　　　　文献を読む
　　　　　　例9.3——利息を得る　文献を用いた場合
　　　　　　何度でも挑戦すること
　　　それほど明白でない概念をモデル化する方法
　　　　　　明示的な制約
　　　　　　例9.4——再考：オーバーブッキングポリシー
　　　　　　ドメインオブジェクトとしてのプロセス
　　　仕様（SPECIFICATION）
　　　　　　仕様の適用と実装
　　　　　　例9.5——化学製品倉庫での格納
　　　　　　例9.6——倉庫内格納サービスの、実際に動作するプロトタイプ

**デフォルトの名無しさん** · 2017/10/24(火) 19:44:14.81

第10章しなやかな設計
　　　意図の明白なインタフェース（INTENTION-REVEALING INTERFACES）
　　　　　　例10.1——リファクタリング：塗料混合アプリケーション
　　　副作用のない関数（SIDE-EFFECT-FREE-FUNCTIONS）
　　　　　　例10.2——リファクタリング：塗料混合アプリケーション再考
　　　表明（ASSERTIONS）
　　　　　　例10.3——塗料の混合に戻る
　　　概念の輪郭（CONCEPTUAL CONTOURS）
　　　　　　例10.4——発生の輪郭
　　　独立したクラス（STANDALONE CLASSES）
　　　閉じた操作（CLOSURE OF OPERATIONS）
　　　　　　例10.5——コレクションから選択する
　　　宣言的な設計
　　　　　　ドメイン特化言語
　　　設計の宣言的スタイル
　　　　　　宣言的スタイルで仕様を拡張する
　　　　　　例10.6——コンポジット仕様を実装する他の方法
　　　攻める角度
　　　　　　サブドメインを切り取る
　　　　　　可能な場合には、確立された形式主義を活用する
　　　　　　例10.7——パターンを統合する：シェア算

**デフォルトの名無しさん** · 2017/10/24(火) 19:44:34.64

第11章アナリシスパターンを適用する
　　　　　　例11.1——利息を得る　勘定を用いた場合
　　　　　　例11.1（続き）——夜間バッチについての洞察
　　　　　　アナリシスパターンは活用すべき知識である

第12章デザインパターンをモデルに関係づける
　　　ストラテジー（STRATEGY）（別名　ポリシー（POLICY））
　　　　　　例12.1——経路検索ポリシー
　　　コンポジット（COMPOSITE）
　　　　　　例12.2——経路で構成された輸送経路
　　　なぜ、フライウェイトではないのか？

第13章より深い洞察へ向かうリファクタリング
　　　開始
　　　探究チーム
　　　先達の技
　　　開発者のための設計
　　　タイミング
　　　好機となる危機

**デフォルトの名無しさん** · 2017/10/24(火) 19:45:17.29

第4部　戦略的設計

第14章モデルの整合性を維持する
　　　境界づけられたコンテキスト（BOUNDED CONTEXT）
　　　　　　例14.1——予約コンテキスト
　　　　　　境界づけられたコンテキスト内での分派を認識する
　　　継続的な統合（CONTINUOUS INTEGRATION）
　　　コンテキストマップ（CONTEXT MAP）
　　　　　　例14.2——輸送アプリケーションにおける2つのコンテキスト
　　　　　　コンテキストの境界で行うテスト
　　　　　　コンテキストマップを構成してドキュメント化する
　　　境界づけられたコンテキスト間の関係
　　　共有カーネル（SHARED KARNEL）
　　　顧客／供給者の開発チーム（CUSTOMER/SUPPLIER DEVELOPMENT TEAMS）
　　　　　　例14.3——収益分析と予約
　　　順応者（CONFORMIST）
　　　腐敗防止層（ANTICORRUPTION LAYER）
　　　　　　腐敗防止層のインタフェースを設計する
　　　　　　腐敗防止層を実装する
　　　　　　例14.4——レガシー予約アプリケーション
　　　　　　訓話

**デフォルトの名無しさん** · 2017/10/24(火) 19:45:38.94

　　　別々の道（SEPARATE WAYS）
　　　　　　例14.5——保険プロジェクトの縮小化
　　　公開ホストサービス（OPEN HOST SERVICE）
　　　公表された言語（PUBLISHED LANGUAGE）
　　　　　　例14.6——化学のための公表された言語
　　　象のモデルを統一する
　　　　　　モデルコンテキスト戦略を選択する
　　　　　　チームでの意思決定と、より上層での意思決定
　　　　　　コンテキストに自らの身を置く
　　　　　　境界を変換する
　　　　　　変更できないものを受け入れる：外部システムの輪郭を描く
　　　　　　外部システムとの関係
　　　　　　設計中のシステム
　　　　　　別のモデルで特殊な要求を満たす
　　　　　　デプロイ
　　　　　　トレードオフ
　　　　　　すでにプロジェクトが進行中の場合
　　　変換
　　　　　　コンテキストをマージする：別々の道 → 共有カーネル
　　　　　　コンテキストをマージする：共有カーネル → 継続的な統合
　　　　　　レガシーシステムを段階的に廃止する
　　　　　　公開ホストサービス → 公表された言語