『エリック・エヴァンスのドメイン駆動設計』
https://gyazo.com/7500084c54104f56967fbd6b3eda0eab
2003/8/20
読み始めた動機
なんちゃってDDDしか知らないのと、大量のブログを読むのは非効率だと感じたため
文章がめちゃくちゃわかりづらいなmrsekut.icon
無駄に読み手の負荷が高い
第I部 ドメインモデルを機能させる
第1章 知識をかみ砕く
第2章 コミュニケーションと言語の使い方
ドキュメントは、コードや会話の表現を補足する役割を果たす
コードがやっていることを、ドキュメントでもやる必要はない
第3章 モデルと実装を結びつける
モデルを唯一つにする
コードとモデルを対応させる
手続き型言語では、モデル駆動設計はできない
理由がいまいちわからないが、意図が乗りにくいということだろうかmrsekut.icon
具体例がないのでわかりづらい
伝えたい内容に対して、文量多すぎない？mrsekut.icon
第2部 モデル駆動設計の構成要素
第4章 ドメインを隔離する
第5章 ソフトウェアで表現されたモデル
関連
例5.1——証券取引口座における関連
モジュール（MODULES）（別名 パッケージ（PACKAGES））
アジャイルモジュール
例5.3——Javaにおけるパッケージのコーディング規約
インフラストラクチャ駆動パッケージングの落とし穴
モデリングパラダイム★
なぜオブジェクトパラダイムが主流なのか？
オブジェクトの世界におけるオブジェクトではないもの
パラダイムを混在させる際にはモデル駆動設計に忠実であること
第6章 ドメインオブジェクトのライフサイクル
この章の目的は、オブジェクトのライフサイクルの扱いを考える
以下2つの達成したいことがある
ライフサイクルの中で整合性を維持する
例え、ライフサイクルが複雑であっても、モデルがその影響を受けないようにする
これらの課題を3つのパターンで解決する
object (Entity)同士の関係、境界
object (Aggregate)の生成、再構築の管理
object (Aggregate)の永続化の管理
第7章 言語を使用する：応用例
貨物輸送システムを導入する
ドメインを隔離する：アプリケーションの導入
エンティティと値オブジェクトを区別する
役割とその他の属性
輸送ドメインの関連を設計する
集約の境界★
リポジトリを選択する
シナリオをウォークスルーする
サンプルアプリケーションの機能：貨物の荷出し地を変更する
サンプルアプリケーションの機能：リピータへの対応
オブジェクトの生成
貨物用のファクトリとコンストラクタ
荷役イベントを追加する
リファクタリングのために立ち止まる：貨物集約についてのもう1つの設計
輸送モデルにおけるモジュール
新機能を導入する：配分チェック
2つのシステムを接続する
モデルを強化する：ビジネスのセグメント化
パフォーマンスチューニング
最後に
第3部 より深い洞察へ向かうリファクタリング
3部読む前にこれを倍速で見れば概要が掴める
https://www.youtube.com/watch?v=T4niXwK6Zhk&t=3410s
ドメインについての新しい洞察を得た時に行うリファクタリングが、システムに最も影響を与える
「ただコードをきれいにしよう」というレベルではない
この3部から8章までの文章、良いこと書いているmrsekut.icon
こころなしか、第3部の訳は読みやすいなmrsekut.icon
第8章 ブレイクスルー
ブレイクスルーの具体例を1つ紹介されている章
流れとしては
実装が複雑だったりコーナーケースが多い箇所にぎこちなさを感じる
そこをよく考えドメインに対する洞察を深めることで、良い構造を思いつく
これのことをブレイクスルーと呼んでいる
実装がシンプルになり、考えることが減る
この具体例では、Domain Expertが理解している構造も誤っていた
良い構造を適用するためにリリース前だがリファクタして良い感じになった
第9章 暗黙的な概念を明示的にする
相変わらず具体例が難しいmrsekut.icon
第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.1——利息を得る 勘定を用いた場合
例11.1（続き）——夜間バッチについての洞察
アナリシスパターンは活用すべき知識である
第12章 デザインパターンをモデルに関係づける
ストラテジー（STRATEGY）（別名 ポリシー（POLICY））
例12.1——経路検索ポリシー
コンポジット（COMPOSITE）
例12.2——経路で構成された輸送経路
なぜ、フライウェイトではないのか？
第13章 より深い洞察へ向かうリファクタリング
開始
探究チーム
先達の技
開発者のための設計
タイミング
好機となる危機
第4部 戦略的設計
大きめのプロダクトを複数チームで作る際にどうするかみたいな話が、14~16章
大きめのプロダクト全体でユビキタス言語を統一したり、するのではなく、境界を明確に引き、その中で統一性を保とう、というのが14章 1つ1つから無駄なものを省いたモデルを作ろうみたいな話が15章
境界づけられた1つ1つのモデルを境界を保ったまま統合しようとする話が16章
第14章 モデルの整合性を維持する
継続的な統合（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——化学のための公表された言語
象のモデルを統一する
モデルコンテキスト戦略を選択する
チームでの意思決定と、より上層での意思決定
コンテキストに自らの身を置く
境界を変換する
変更できないものを受け入れる：外部システムの輪郭を描く
外部システムとの関係
設計中のシステム
別のモデルで特殊な要求を満たす
デプロイ
トレードオフ
すでにプロジェクトが進行中の場合
変換
コンテキストをマージする：別々の道 → 共有カーネル
コンテキストをマージする：共有カーネル → 継続的な統合
レガシーシステムを段階的に廃止する
公開ホストサービス → 公表された言語
コアドメイン（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つのこと
同じことが技術的なフレームワークにも当てはまる
マスタプランに注意すること