エリック・エヴァンスのドメイン駆動設計を読んでいる ( 2 )
ドメインモデルを機能させる
前置き
業務知識をそのまま落とし込むことでなく、アプリケーションを育てていく上での良い形に落とし込んでいく事が重要そう
- ドメインエキスパート（対象業務の有識者）の頭の中にある知識でなくて、
厳密に構成されて抽象化されたもの - 現実をそのまま写すことではない
- ドメインエキスパートと、会話ができて開発者と同じモデルを見て話せる状態
- 選択したモデルが、言語の基盤（開発する上でコミュニケーションがとれる形に）
- モデルを通じて、どう業務を理解したか、どう選択/分解したかが分かること
ソフトウエアの核心
ドメインに関係した問題をユーザーのために解決する事。
- たいていの開発者は、ドメインに関係した問題を最重要視しない
- 技術的な解決を、専門分野、スキルを重視してしまう（わかる…）
- ドメインに関係した知識は、自分の能力を伸ばすものに見えない
- しかし、それを技術で解決しようとして的外れな解決をしてしまう
- でも実際には「複雑性」を解決するスキル価値のあるもの
知識を噛み砕く
ドメインエキスパート共同作業でモデルを作り上げる
- モデルは実装と紐づくこと（紐づかないならどちらかを直す）
- ドメインエキスパートは、開発者と（スケッチなどツールを使ったりも含める）
- 無駄なものは削ぎ落とす
無駄なものってなんだろう？現状のアプリケーションには必要ないってこと？ - ウオーターフォールではうまく行かない
開発者からのフィードバックによるリファクタがなく、一方通行 - 目指せ好循環
継続的学習
知識はメンバーの中に育つ。意識的に育てる必要がある。
知識豊富な設計
モデルとなるものは、「名詞」そのものに止まらない
- ルールも活動もモデル
- エンティディや値を超えてその先にいこうとする事が大事
これ、クラス設計においても例えば「Post（投稿）」ってモデルがあって、その投稿ルールをモデルにそのまま実装するのでなく「PostPolicy」クラスに分けるとべき - これにより、開発者とさらにそれ以外の人にもコードを見せることで理解が得られやすい
