- 複数形であるところがポイント
- ここから。今日は15章を終えるつもり
- 再利用ではなく汎用であるということ
- コンポネント設計についてもこれが答えだと思う
- 再利用することを考えるコストを払うなら、ビジネスに必要なところを必要なだけ実装すべき
- Just In Time
- 技術のリスクとドメインモデリングのリスク
- ドメインモデリングのリスクは容易に過小評価されてしまう
- 要求開発とかの文脈と同じものを見ていそう
- コアドメインがリスク高い
- 予想に反して難解だが
- コアドメインなしにプロジェクトが成功することはありえない
- そうだね
- インセプションデッキに親しいものを感じる
- ビジョン声明文
資金に都合がつけば捨てられ、実際の開発で使われることも、開発者が読むこともない
- まじかよ
- ドメインビジョン声明文はそういうものではない
- 価値の提議 Value proposition
- ドメインが多様な関心事にどう役に立つかを完結に記述する
- 例を見てみる
- Good case
- whatを書いている
- No good case
- howしか書いていない
- Good case
身長に選んだ図やドキュメントが数点あれば、チームは精神的なよりどころやエントリポイントを得られるのだ。 こういう問題は、UMLモデルを使用するプロジェクトでも、コードを主要なリポジトリとするプロジェクトでも同様に発生する。
- コアドメインを協調するのだ
- 簡潔なドキュメントを書き、コアドメインとコアを構成する要素間の主要な相互作用を記述すること
- 陳腐化を避けるには
- ミニマリズムに徹する
- ありふれた詳細からは距離を取り、中心的な抽象とその相互作用に集中
- チームの非技術的なメンバーが理解できるように書く
- 巨大なドキュメント
- コア自体と補助機能との関係を明確に示すモデルの道案内
モデルの主要なリポジトリ内においてコアドメインの各要素にフラグを立てること コアに入るものとそうでないものを開発者が楽にわかるようにすること
主要なリポジトリ == プロジェクトごとに変わる。巨大なドキュメントだったりコードだったり何枚もの絵だったり
- 更新し続けて全員に共有し続けよう的な
- プロセスに完全に組み込まれたドキュメントの姿
- 理想的な状態
- howが染み出すことがある
- howは凝集してもれないようにしよう
- ノードの関連といえばGraph
- みんなが知ってる公的なフレームワークだし、howが凝集されているのでシンプル。理解しやすい
* 気になるところ
* 汎用サブドメイン
* ドメインの一部という意味ではコアドメインと違いはない
* やや中心から外れているだけ
* 凝集されたメカニズム
* ドメインを表現しない
* 面倒な処理を解決するだけ
モデルが提案 propose し、凝集されたメカニズムが処理 dispose する
- メカニズムが主要な価値であるケース
- 輸送手配アルゴリズム
- 投資銀行のリスク評価アルゴリズム
一巡することはよくあるが、出発点に戻っているのではない
- 設計が深化していくと
- 意図の明白なインタフェース
- 一貫性のある表明
- 副作用のない関数
- で宣言的な意味のある記述となる
- fogがcoreに分離された的な
- たいへんだしコストがかかるけど頑張る価値はある、けど大変だ
- 隔絶されたコアにするにはチームが一丸となっていなければならない
- 俊敏で同じ見方を共有できているくらい、ハイレベルなチームが求められる
- とても面白い
- ちゃんと見ていこう
- 配送 Delivery と輸送 Transportation
- 顧客合意
- 顧客自体はコアではなかった
- 顧客は汎用サブドメインとなれる
- 水平に引く
- セグメントではなく抽象度で分割する
- フレームワークっぽい
- インタフェースでクラス間の関係性による設計を洗練させられればハマる
深い洞察に向かう継続的なリファクタリングによって行われ、深いモデルやしなやかな設計へと駆り立てる
もっとも価値があるのはコアドメインにおいて発生したとき
- nit-pickリファクタリング
- ありがち
- それがコアドメインなのかサブドメインなのかをしっかり考えて
- 歯を食いしばってやっていこう