実施日時：2019/12/25
対象範囲：第4章
参加者：yodai、くめごん、masuda220、kassyi

小さな部品を作ってそれを集める
役に立つドメインオブジェクトは業務の言葉とクラス名とメソッド名が一致する
業務の知識がふわふわしていると危ない
プログラム側から問題領域を理解する手がかりが見つかることがある。
これは、業務用語をより論理的にしてソフトウェアをより分かりやすくする手がかりになる。
業務知識が不足していても、理解した範囲で実装してみるのが大切
ソースコードで業務の要求しようを表現することをプログラムの自己文書化と呼ぶ
クラス名とメソッド名を業務の関心事と一致させることで、プログラムを変更が容易で分かりやすくする。
早い段階からコードを書いて段階的にコードを成長させていくのがドメインモデル設計のやり方。
業務を理解→コードを書く→自己文書化→業務を理解→コードを書く・・・
ドメインモデル設計の基本：
　重要な言葉とそうでない言葉を判断する。
　言葉と言葉の関連性を見つける
言語化していない業務知識は担当者と会話をするのが早い
聞きなれない言葉や理解できない言葉は、聞き逃したり、知ってる言葉に置き換えたり、勝手に解釈しがち
自分は業務の言葉を正しく聞き取れていないという自覚をする
業務知識の可視化は、ホワイトボードや課題管理表などをメールでやり取りするなどがある。
形式的なドキュメントを作成するより、本質を理解する方が重要で効果的。
業務知識を増やすには、文章を読んで理解した後に担当者と会話を行う。
最低限の知識を本などで付けるのが大切
関係者で設計レビューを行い、自分の言葉で業務を説明できるようにする。
できなければドメインモデルを見直す。
若手、メンバーをなるべくお客様とのやり取りに参加させると良い