ユースケースから始めるドメイン駆動設計の手法を紹介
台風で予定がなくなったので久しぶりにがっつり書きました。
概要
最近、DDDによる開発が盛んですね。
DDDはひたすらドメインを分析してモデリングしていくための手法ですが、ユースケース駆動開発とはとても相性が良いと感じています。
そこでユースケース駆動開発から始めるドメイン駆動設計の手法を紹介したいと思います。
ドメインレベルにクラスを落とし込むことまでを目的としています。
ユースケースから実装までの流れがつかめればと思います。
0. 機能要件
どんなシステムを開発するにしても要求というものは存在します。
「顧客が抱えている問題は何か」を理解し「システムが何を提供できるか」を定義するフェーズになります。
例として「食生活の管理がしたい。」をもとに設計してみたいと思います。
#####機能要求
- 毎食の食事のメニューを登録できる。
- 食材を登録することができる。
- 毎食の食事をメニューから選択して登録することができる。
- 過去に食べた食事の内容を確認することができる。
1. ドメインモデリング
最初のドメインモデリングではモデル候補を洗い出すことを目指します。
ここで洗い出したモデル候補をドメインモデルへと育てていくことになるのですが、最初の段階で完璧に洗い出すことはできないのであまり時間をかけ過ぎるのは得策ではありません。
以降のユースケースモデリングやロバストネスモデリングではここで洗い出したモデルを修正したり加えたリしながら育てていくことになるので最初にすべて洗い出せなくても気にすることはありません。
モデルの見つけ方は顧客とのヒアリングで出てきた単語がキーになります。
顧客との会話の中で出てきた単語のうちの名詞がモデル候補で動詞は振る舞い候補となります。
2. ユースケースモデリング
次にユースケースモデリングを行います
ユースケース記述は以下の事に注意して書く。
ユースケース分析の結果をレビューしドメインモデルを適宜更新する。
- 主語、述語、目的語で簡潔に書く。
- ユーザーとシステムの両側を書く。
ユースケース図
ユースケース記述
| - | 食材を登録することができる |
|---|---|
| 基本1 | ユーザーは食材登録画面にアクセスする。 |
| 基本2 | システムは食材登録画面を表示する |
| 基本3 | ユーザーは食材名とカロリーを入力して登録ボタンをクリックする。 |
| 基本4 | システムは入力内容をチェックしてデータストアに登録する。(代替1) |
| 基本5 | システムは登録完了画面を表示する。 |
| 代替1 | システムは入力内容に不備があることを食材登録画面へ表示する。 |
| - | 毎食の食事のメニューを登録できる |
|---|---|
| 基本1 | ユーザーはメニュー登録画面にアクセスする。 |
| 基本2 | システムはメニュー登録画面を表示する |
| 基本3 | ユーザーは食材を選択し、メニュー名を入力して登録ボタンをクリックする。 |
| 基本4 | システムは入力内容をチェックしてデータストアに登録する。(代替1) |
| 基本5 | システムは登録完了画面を表示する。 |
| 代替1 | システムは入力内容に不備があることをメニュー登録画面へ表示する。 |
| - | 毎食の食事をメニューから選択して登録することができる |
|---|---|
| 基本1 | ユーザーは食事登録画面にアクセスする。 |
| 基本2 | システムは食事登録画面を表示する |
| 基本3 | ユーザーはメニューと日時、ラベルを入力して登録ボタンをクリックする。 |
| 基本4 | システムは入力内容をチェックしてデータストアに登録する。(代替1) |
| 基本5 | システムは登録完了画面を表示する。 |
| 代替1 | システムは入力内容に不備があることを食事登録画面へ表示する。 |
| - | 過去に食べた食事の内容を確認することができる |
|---|---|
| 基本1 | ユーザーは食事確認画面にアクセスする。 |
| 基本2 | システムは食事登録画面を表示する |
| 基本3 | ユーザーは日付を選択して確認ボタンをクリックする。 |
| 基本4 | システムは入力内容を確認してデータストアからデータを日時昇順で取得する。(代替1) |
| 基本5 | システムは食事確認画面へ結果を表示する。 |
| 代替1 | システムは入力内容に不備があることを食事確認画面へ表示する。 |
3. ロバストネス分析
ロバストネス図はユースケース記述とドメインモデルを元に記述する。
ユースケース記述の名詞はエンティティ候補であり動詞は振る舞い候補になる。
また、ロバストネス図上のエンティティはドメインモデルと過不足無く一致していなければならない。
ロバストネス分析の結果をレビューしユースケース記述とドメインモデルを適宜更新する。
ロバストネス図
4. シーケンス図
さて、ロバストネス図までおわりました。
次はシーケンス図を描きます。
シーケンス図が描ければクラス図の関係がわかり詳細設計が出来たも同然となります。
シーケンス図はドメインモデルのモデルとロバストネス図のコントローラーを使って描いていきます。
ここまでは順調にできました。
早速はじめてみたいのですがシーケンス図を描き始めて何かがおかしいことに気が付くはずです。
そう、このままだとシーケンス図が描けないのです。
試しにシーケンス図を描いてみます。
おーー！なんか描けました。
いたって普通のシーケンス図が描けました。
「めでたしめでたし」ではないですよね＾＾；
やりたいことはDDDでしたね。
何がイケてなかったのだろうか。
シーケンス図はロバストネス図を元に描いていくのできっとロバストネス図が悪かったはずです。
というわけでロバストネス図を描き直してみます。
#####修正したロバストネス図
上記はアプリケーション（ユースケース）と集約ルートとドメインモデルとリポジトリを使って作り変えたものです。
それでは上記のロバストネス図を元にもう一度シーケンス図を描いてみます。
#####シーケンス図
それっぽいシーケンス図になりました。
作成されたシーケンス図はユースケース記述と合致しているか（要件を満たしているか）を確認し、ロバストネス図とドメインモデルとも合致しているかレビューをします。
5. クラス図
シーケンス図とロバストネス図からドメインモデルを更新してクラス図を作成してみます。
大変な駆け足でつくったので見苦しい点はあるかと思いますが１つめのユースケースだけは何とか完成しました。
ちゃんと見直したら修正したい箇所は沢山出てくると思いますが、DDDに落とし込むまでの流れがざっくり掴めれば十分だと思います。