AdventureWorksをモデリングしてDDDしながらドメインモデルで実装してみる（５）
ビジネスルールの識別はロバストネス分析の利用もお勧め
前回識別したビジネスルールですが、分析にはロバストネス分析を利用する方法もやり易い方法です。ユーザ機能からサービスを識別してビジネスルールを整理します。
ビジネスルールで利用された用語をエンティティに定義していく
識別・定義したビジネスルールにはエンティティの状態や重要な概念（用語）が記述されています。これらのうち再利用が期待できる便利なものを識別してエンティティ上に定義します。
たとえば、最初のビジネスルール「休暇が申請できるのは（ONLY IF)従業員が在籍している場合だけである 」から従業員に「在籍」という概念が存在することが識別できます。これを、従業員エンティティに定義して共通化して再利用を期待します。
基本的な進め方は、派生ルールはそのまま導出項目として定義、制約ルールは制約の条件部を導出項目と見立てて定義します。このように考えて識別すると以下のような導出項目の候補が得られます。
- 「従業員が在籍している」→Is在籍
- 「休暇残り時間（VacationHours）は0未満」→Is休暇残り時間0以上
- 「開始日時<=終了日時」→Is有効な期間
- 「マネージャがいない申請者」→Hasマネージャ
- 「申請者の稼動時間」→Get稼働時間(期間)
識別した導出項目は分析モデルに割り当てる必要があります。分析時の責務の割り当ては基本「情報エキスパートパターン*1」で考えます。Get稼働時間以外はほぼ自明です。Get稼働時間は「申請者の」とあるので従業員に割り当てればよさそうですが、従業員の稼働時間の定義は勤務シフトにあるため「情報エキスパートパターン」として考えれば勤務シフトのメソッドとも考えられます。まあ、分析時は識別作業が中心でそれほど厳密でなくてもよいので、「稼働時間が申請者の勤務シフトより計算する」ことが明確でない場合は従業員のメソッドとしておいても問題ないでしょう。*2
さらに、従業員部署履歴から導出される現部署や現勤務シフトなどのよく利用されそうなものを追加して分析モデルは以下のようにしました。
メソッドやプロパティとしてクラス図に表現していますが、エンティティごとに用語集を作成してそこに日本語で記述することも良い方法です。実際に仕様を提供している方にも理解可能な資料のほうが役に立つことが多いからです。
