調べたことをまとめておきます。
認識違いなどありましたらコメントいただけると幸いです。
ドメインモデリングとは
システムに関する業務知識（ドメイン）を簡潔に整理(要約・モデル化)し、その関係性がわかるようにすること
なんのためにやるの？
- ドメインに対する理解を深める
- メンバー内でドメインに対する認識を合わせる
具体的には何をやるの？
- 業務用語集を作る
- 業務用語の関係図を描く
業務用語集を作る
まず業務を知る
- マニュアルや利用者ガイドを読んでみる
- 業務の一般的な知識を書籍などで勉強する
- どんなデータがあるか画面やファイルを調べる
- 業務経験者（ドメインエキスパート）と会話する
業務内容から名詞句を集める
- 業務内容を文章で書き、そこから重要そうな名詞句（ヒト、モノ、コト）を抜き出す
- 特にコトに注目するとそれぞれの複雑な関係を紐解きやすい
| 分類 | 事例 |
|---|---|
| ヒト | 個人、企業、担当者など |
| モノ | 商品、場所、権利、義務など |
| コト | 予約、注文、キャンセルなど |
例
アカウントに対して更新権限を持つユーザーは、アカウント配下にキャンペーン、その配下に広告グループ、その配下に広告とキーワードをそれぞれ登録できなければなりません。
↓
アカウントに対して更新権限を持つユーザーは、アカウント配下にキャンペーン、その配下に広告グループ、その配下に広告とキーワードをそれぞれ登録できなければなりません。
- ヒト
- 更新権限を持つユーザー
- モノ
- アカウント、キャンペーン、広告グループ、広告、キーワード
- コト
- （キャンペーン|広告グループ|広告|キーワード）を登録する
業務用語の関係図を描く
- クラス図のように集約と汎化で関係付けていく
- 集約（A has-a B）
- 汎化（A is-a B）
例
※ただしこの図は正しくありません
注意点
- 正しさを求めすぎない
- キリがないため。最初は2時間以上かけない。
- 細かく書きすぎない
- 大事なのは全体を網羅すること、一部に集中しすぎると全体が見えにくくなる。
- データモデルにはしない
- DBやモノに注目しすぎるとデータモデルになってしまう。それよりも大きい枠組みで業務の関心ごとを捉える。（コトに注目するとやりやすい）
ドメインモデリングのゴール
ない。
ドメインモデリングは変化し続ける業務ロジックを追って、常により良い認識（解答）を探し続けていく。
DDDの次のステップ
- ユースケース図を作ったりロバストネス解析をやってドメインモデル図を精錬していく
- ドメインモデル図をそのままコードに落としていく。（ここも難しいらしい）
まとめ
- ドメインモデリングとは、業務知識を要約し、関係性を明らかにすること
- 業務内容の名詞句（特にコト）に注目しながらドメインを洗い出す
- いっぺんに完璧を目指さず、常に改善し続ける