エリックエヴァンスのドメイン駆動設計

[otakumesi]

• [ ] 第1部　ドメインモデルを機能させる
  • [ ] ドメイン駆動設計におけるモデルの有用性
  • [ ] ソフトウェアの核心
• [ ] 第1章 知識をかみ砕く
  • [ ] 効果的なモデリングの要素
  • [ ] 知識のかみ砕き
  • [ ] 継続的学習
  • [ ] 知識豊富な設計
  • [ ] 例1.1——隠された概念を引き出す
  • [ ] 深いモデル
• [ ] 第2章 コミュニケーションと言語の使い方
  • [ ] ユビキタス言語（UBIQUITOUS LANGUAGE）
  • [ ] 例2.1——貨物輸送プログラムを完成させる
  • [ ] 声に出してモデリングする
  • [ ] 1つのチームに1つの言語
  • [ ] ドキュメントと図
  • [ ] 書かれた設計ドキュメント
  • [ ] 実行可能な基盤
  • [ ] 説明のためのモデル
  • [ ] 例2.2——輸送業務と経路
• [ ] 第3章 モデルと実装を結びつける
  • [ ] モデル駆動設計（MODEL-DRIVEN DESIGN）
  • [ ] モデリングパラダイムとツールによるサポート
  • [ ] 例3.1——手続き型からモデル駆動へ
  • [ ] 骨格を見せる：なぜモデルがユーザにとって重要なのか？
  • [ ] 実践的モデラ（HANDS ON MODELERS）
• [ ] 第2部　モデル駆動設計の構成要素
• [ ] 第4章 ドメインを隔離する
  • [ ] レイヤ化アーキテクチャ（LAYERED ARCHITECTURE）
  • [ ] 例4.1——オンラインバンキングの機能をレイヤに分割する
  • [ ] レイヤを関係づける
  • [ ] アーキテクチャフレームワーク
  • [ ] ドメイン層はモデルが息づく場所
  • [ ] 利口なUI「アンチパターン」（SMART UI ﾒANTI-PATTERNﾓ）
  • [ ] その他の隔離
• [ ] 第5章 ソフトウェアで表現されたモデル
  • [ ] 関連
  • [ ] 例5.1——証券取引口座における関連
  • [ ] エンティティ（ENTITIES）（別名　参照オブジェクト（REFERENCE OBJECTS））
  • [ ] エンティティをモデル化する
  • [ ] 同一性のための操作を設計する
  • [ ] 値オブジェクト（VALUE OBJECTS）
  • [ ] 値オブジェクトを設計する
  • [ ] 例5.2——値オブジェクトを使ってデータベースをチューニングする
  • [ ] 値オブジェクトを含む関連を設計する
  • [ ] サービス（SERVICES）
  • [ ] サービスと隔離されたドメイン層
  • [ ] 粒度
  • [ ] サービスへのアクセス
  • [ ] モジュール（MODULES）（別名　パッケージ（PACKAGES））
  • [ ] アジャイルモジュール
  • [ ] 例5.3——Javaにおけるパッケージのコーディング規約
  • [ ] インフラストラクチャ駆動パッケージングの落とし穴
  • [ ] モデリングパラダイム
  • [ ] なぜオブジェクトパラダイムが主流なのか？
  • [ ] オブジェクトの世界におけるオブジェクトではないもの
  • [ ] パラダイムを混在させる際にはモデル駆動設計に忠実であること
• [ ] 第6章 ドメインオブジェクトのライフサイクル
  • [ ] 集約（AGGREGATES）
  • [ ] 例6.1——購入注文の整合性
  • [ ] ファクトリ（FACTORIES）
  • [ ] ファクトリとその場所を選択する
  • [ ] コンストラクタがあればよい場合
  • [ ] インタフェースを設計する
  • [ ] 不変条件のロジックはどこへ置くべきか？
  • [ ] エンティティファクトリ対値オブジェクトファクトリ
  • [ ] 格納したオブジェクトを再構成する
  • [ ] リポジトリ（REPOSITORIES）
  • [ ] リポジトリに対して問い合わせる
  • [ ] クライアントのコードはリポジトリの実装を無視するが、開発者はそうではない
  • [ ] リポジトリを実装する
  • [ ] フレームワークの範囲内で作業する
  • [ ] ファクトリとの関係
  • [ ] 関係データベースに合わせてオブジェクトを設計する
• [ ] 第7章 言語を使用する：応用例
  • [ ] 貨物輸送システムを導入する
  • [ ] ドメインを隔離する：アプリケーションの導入
  • [ ] エンティティと値オブジェクトを区別する
  • [ ] 役割とその他の属性
  • [ ] 輸送ドメインの関連を設計する
  • [ ] 集約の境界
  • [ ] リポジトリを選択する
  • [ ] シナリオをウォークスルーする
  • [ ] サンプルアプリケーションの機能：貨物の荷出し地を変更する
  • [ ] サンプルアプリケーションの機能：リピータへの対応
  • [ ] オブジェクトの生成
  • [ ] 貨物用のファクトリとコンストラクタ
  • [ ] 荷役イベントを追加する
  • [ ] リファクタリングのために立ち止まる：貨物集約についてのもう1つの設計
  • [ ] 輸送モデルにおけるモジュール
  • [ ] 新機能を導入する：配分チェック
  • [ ] 2つのシステムを接続する
  • [ ] モデルを強化する：ビジネスのセグメント化
  • [ ] パフォーマンスチューニング
  • [ ] 最後に
• [ ] 第3部　より深い洞察へ向かうリファクタリング
  • [ ] リファクタリングのレベル
  • [ ] 深いモデル
  • [ ] 深いモデル／しなやかな設計
  • [ ] 発見のプロセス
• [ ] 第8章 ブレイクスルー
  • [ ] ブレイクスルーの話
  • [ ] 悪くないモデルなのだが…
  • [ ] ブレイクスルー
  • [ ] さらに深いモデル
  • [ ] 冷静な意思決定
  • [ ] 結末
  • [ ] 好機
  • [ ] 基本への集中
  • [ ] エピローグ：新しい洞察の連鎖
• [ ] 第9章 暗黙的な概念を明示的にする
  • [ ] 概念を掘り出す
  • [ ] 言葉に耳を傾ける
  • [ ] 例9.1——輸送モデルに欠けている概念を聞き分ける
  • [ ] ぎこちなさを精査する
  • [ ] 例9.2——利息を得る　難しい方法
  • [ ] 矛盾について熟考する
  • [ ] 文献を読む
  • [ ] 例9.3——利息を得る　文献を用いた場合
  • [ ] 何度でも挑戦すること
  • [ ] それほど明白でない概念をモデル化する方法
  • [ ] 明示的な制約
  • [ ] 例9.4——再考：オーバーブッキングポリシー
  • [ ] ドメインオブジェクトとしてのプロセス
  • [ ] 仕様（SPECIFICATION）
  • [ ] 仕様の適用と実装
  • [ ] 例9.5——化学製品倉庫での格納
  • [ ] 例9.6——倉庫内格納サービスの、実際に動作するプロトタイプ
• [ ] 第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——パターンを統合する：シェア算
• [ ] 第11章 アナリシスパターンを適用する
  • [ ] 例11.1——利息を得る　勘定を用いた場合
  • [ ] 例11.1（続き）——夜間バッチについての洞察
  • [ ] アナリシスパターンは活用すべき知識である
• [ ] 第12章 デザインパターンをモデルに関係づける
  • [ ] ストラテジー（STRATEGY）（別名　ポリシー（POLICY））
  • [ ] 例12.1——経路検索ポリシー
  • [ ] コンポジット（COMPOSITE）
  • [ ] 例12.2——経路で構成された輸送経路
  • [ ] なぜ、フライウェイトではないのか？
• [ ] 第13章 より深い洞察へ向かうリファクタリング
  • [ ] 開始
  • [ ] 探究チーム
  • [ ] 先達の技
  • [ ] 開発者のための設計
  • [ ] タイミング
  • [ ] 好機となる危機
• [ ] 第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——レガシー予約アプリケーション
  • [ ] 訓話
  • [ ] 別々の道（SEPARATE WAYS）
  • [ ] 例14.5——保険プロジェクトの縮小化
  • [ ] 公開ホストサービス（OPEN HOST SERVICE）
  • [ ] 公表された言語（PUBLISHED LANGUAGE）
  • [ ] 例14.6——化学のための公表された言語
  • [ ] 象のモデルを統一する
  • [ ] モデルコンテキスト戦略を選択する
  • [ ] チームでの意思決定と、より上層での意思決定
  • [ ] コンテキストに自らの身を置く
  • [ ] 境界を変換する
  • [ ] 変更できないものを受け入れる：外部システムの輪郭を描く
  • [ ] 外部システムとの関係
  • [ ] 設計中のシステム
  • [ ] 別のモデルで特殊な要求を満たす
  • [ ] デプロイ
  • [ ] トレードオフ
  • [ ] すでにプロジェクトが進行中の場合
  • [ ] 変換
  • [ ] コンテキストをマージする：別々の道 → 共有カーネル
  • [ ] コンテキストをマージする：共有カーネル → 継続的な統合
  • [ ] レガシーシステムを段階的に廃止する
  • [ ] 公開ホストサービス → 公表された言語
• [ ] 第15章 蒸留
  • [ ] コアドメイン（CORE DOMAIN）
  • [ ] コアを選択する
  • [ ] 誰がこの作業をやるのか？
  • [ ] 蒸留の拡大
  • [ ] 汎用サブドメイン（GENERIC SUBDOMAINS）
  • [ ] 例15.1——2つのタイムゾーンの物語
  • [ ] 汎用とは再利用可能という意味ではない
  • [ ] プロジェクトのリスク管理
  • [ ] ドメインビジョン声明文（DOMAIN VISION STATEMENT）
  • [ ] 強調されたコア（HIGHLIGHTED CORE）
  • [ ] 蒸留ドキュメント
  • [ ] コアにフラグを立てる
  • [ ] プロセスツールとしての蒸留ドキュメント
  • [ ] 凝集されたメカニズム（COHESIVE MECHANISMS）
  • [ ] 例15.2——組織図におけるメカニズム
  • [ ] 汎用サブドメイン対凝集されたメカニズム
  • [ ] メカニズムがコアドメインの一部である場合
  • [ ] 例15.3——一巡：組織図がメカニズムを再び吸収する
  • [ ] 蒸留して宣言的スタイルにする
  • [ ] 隔離されたコア（SEGREGATED CORE）
  • [ ] 隔離されたコアを作成するコスト
  • [ ] チームの意思決定を進化させる
  • [ ] 例15.4——貨物輸送モデルのコアを隔離する
  • [ ] 抽象化されたコア（ABSTRACT CORE）
  • [ ] 深いモデルの蒸留
  • [ ] リファクタリングの対象を選ぶ
• [ ] 第16章 大規模な構造
  • [ ] 進化する秩序（EVOLVING ORDER）
  • [ ] システムのメタファ（SYSTEM METAPHOR）
  • [ ] 「素朴なメタファ」とそれを必要としない理由
  • [ ] 責務のレイヤ（RESPONSIBILITY LAYERS）
  • [ ] 例16.1——深く掘り下げる：輸送システムをレイヤ化する
  • [ ] 適切なレイヤを選択する
  • [ ] 知識レベル（KNOWLEDGE LEVEL）
  • [ ] 例16.2——従業員の給料と年金（1）
  • [ ] 例16.3——従業員の給料と年金（2）知識レベル
  • [ ] 着脱可能コンポーネントのフレームワーク（PLUGGABLE COMPONENT FRAMEWORK）
  • [ ] 例16.4——SEMATECH CIMフレームワーク
  • [ ] 構造による制約をどの程度厳しくするべきか？
  • [ ] ふさわしい構造へのリファクタリング
  • [ ] ミニマリズム
  • [ ] コミュニケーションと自己規律
  • [ ] 再構成によってしなやかな設計がもたらされる
  • [ ] 蒸留によって負荷が軽減される
• [ ] 第17章 戦略をまとめ上げる
  • [ ] 大規模な構造と境界づけられたコンテキストを組み合わせる
  • [ ] 大規模な構造と蒸留を組み合わせる
  • [ ] まず評価する
  • [ ] 誰が戦略を策定するのか？
  • [ ] アプリケーション開発から現れる構造
  • [ ] 顧客に焦点を合わせたアーキテクチャチーム
  • [ ] 戦略的設計上の意思決定を行うために欠かせない6つのこと
  • [ ] 同じことが技術的なフレームワークにも当てはまる
  • [ ] マスタプランに注意すること
• [ ] 結論
  • [ ] エピローグ
  • [ ] 展望