- チームで設計に合意すること
- ドメインモデル図
- モデル名を書いた付箋を模造紙に貼る
- モデル同士の関連を書く
- ドメインオブジェクトの型定義
- 型名、プロパティ、メソッドの形式が分かればよい
- 処理を書くことは任意
1チーム最大7名でモブワークしながら進める
制限はないが以下あたりを想定
- Java
飲み会の割り勘をソフトウェアで解決する
- ユーザ
- 主催者(幹事)
- 参加者
- 主催者が飲み会を開催する
- 支払クラスごとに支払金額負担を追加/削除する
- 開催した飲み会に参加者を追加/削除する
- 飲み会の合計金額を設定する
- 幹事の分担方法を決定する(負担ゼロ、残額負担、クラス指定)
- 主催者も含めて参加者ごとの支払い金額を計算する
- 全員の支払い金額が100%を超えないようにするには…。
- 足りない端数金額は幹事が負担？それもと誰かにカンパしてもらう？
- ユースケースに疑問を感じたらいつでも意見や感想を共有しよう。そこからモデルのヒントが得られるかもしれない
- ユースケースを変更したい場合はスタッフと相談してください。
- ここに示したユースケースは顕在的な要求を表している。実現方法はともかく目的として達成されなければならない
- 一方でまだ言語されていない潜在的な要求もあるかもしれない。余裕があれば考えてみよう
- ドメイン上で扱われる情報だけでなく、意味のある計算処理に注目し、それをメソッドとして定義すること
- 割り勘計算後の実際の支払に関すること。端数金額の支払いの手間はゼロと考えてください。
- HTTPやDB I/Oなどの入出力。リポジトリの実装は無視してよいが、抽象的なインターフェイスは必要ならば考慮に入れて良い
- ドメインモデル(浅いモデル)を洗い出し共有する
- もくもくと考え込まずに声に出す
- 思い付いた概念名を付箋に書き出して共有する
- モデルの種別: ヒト・モノ・コト(コトの例:受注,出荷,入金など)
- ステレオタイプ例: エンティティ、バリューオブジェクト、サービス、ポリシー。まずはエンティティからよい
- その概念の目的を説明してみよう
- 概念と概念の繋がりを線で結び、その線の名前をつける
- 用語に漏れダブりがないか
- 違和感がないか。違和感がすぐに解決しないならメモに残す
以下は一例。他にどんな概念があるか議論してみよう。
| 名前(日本語) | 英語名(任意) | 概要 |
|---|---|---|
| 飲み会 | ||
| 参加者 | ||
| 支払クラス | ||
| ... |
- 概念モデルを実装に反映する
- モデル名はユビキタス言語を反映してください
- UMLで具体的なクラス図を書く代わりに実際にコードにします
- 全体の方針を合意するために、初期実装ではインターフェイス(抽象型)だけで表現する
- どこからどこまでが一つのオブジェクトか、決めてください。場合によってはモデルを見直さないといけないかもしれません
- 必要に応じてテストも追加する
- 今回の場合は、テストがユースケースを表しているとなお良い
- モデルに対してチームで議論し深いモデルへ改善していく。以下 主な設計や実装の観点
- クラス名、プロパティ名、メソッド名はユビキタス言語を反映する
- ユースケース実現のために、役に立つ計算を考える
- 責務の分類と分割
- モジュール(クラス)の責務を考える
- プリミティブ型よりドメイン固有型を選択する
- 不変条件を表明する(型レベル、実行時レベル)
- その場で解決できそうにない問題やリスクについては、赤い付箋でホットスポットとして表現しておく
- 目的に立ち戻り全く新しい方法を提案する(任意)
- チーム内でモデルと実装が一致しているかをレビューする
- チームごとに以下を軸に考えたモデルを共有する
- ドメインモデルの選択と集中
- 議論が白熱したホットスポット