AdventureWorksをモデリングしてDDDしながらドメインモデルで実装してみる（４）
今回はユーザ機能を分析してさまざまなビジネスルールを識別していきたいと思います。
ビジネスルールとは
ビジネスルールを表現にするという風に書いていますが、そもそもビジネスルールについて少し整理しておきます。オブジェクト指向方法序説（ジェームズ・マーチン）によるとビジネスルールは以下のように分類されていています。
- 制約ルール
- 刺激／反応型(WHEN-THEN)
- 操作制約(ONLY IF)
- 構造制約(不変条件)
- 派生ルール
- 推論（IF-THEN）
- 評価（計算・アルゴリズム）
前者の制約ルールは、エンティティが構造的に満たさないといけない条件、特定の処理を行う場合の条件、イベント発生のための条件です。後者の派生ルールは、計算式や条件付き処理などの既存データからの導出される処理と考えれます。
さまざまなビジネスルールを識別する
分析対象のユーザ機能を考える必要がありますが、ここでは「休暇を申請する」を考えたいと思います。
「休暇を申請する」は、休暇の種別（有給休暇と病気休暇）と期間（開始日時、終了日時）を自分のマネージャに申請する機能です。*1
このユーザ機能に対していくつか計算処理や制約が予想されますので検討してきます。
一連の処理の流れをイメージすれば十分識別可能だと思いますが、ここでは先ほどのビジネスルールのパターンに照らし合わせて考えてみます。
まず、制約ルールの「刺激／反応型(WHEN-THEN)」ですが、これはあるイベントが発生して条件が成立した時に処理を実行するように制約する考え方です。今回イベント的な機能は無さそうなので該当するルールは無さそうです。次に「操作制約(ONLY IF)」は操作の事前および事後条件にあたります。今回は「休暇が申請できるのは（ONLY IF)従業員が在籍している場合だけである」が推測されます。制約ルールの最後「構造制約(不変条件)」は操作制約に似ているのですが、操作制約はその操作時のみに成り立てばよい条件ですが、構造制約はいつでも成り立つルールで、全ての操作で成り立つ必要があります。今回は「休暇残り時間（VacationHours）は0未満にならない」や「期間はいつでも開始日時<=終了日時が成り立つ」が考えれれます。
続いて派生ルールの「推論（IF-THEN）」を考えてみます。特定の条件が真の時に結論できるようなルールですが「（IF）マネージャがいない申請者ならば（THEN）申請先の上司は人事担当者になる」のようなものが考えられます。最後の「評価（計算・アルゴリズム）」に相当するものとしては、「休暇時間は申請期間のうちの稼動時間である。」があります。
まだまだあるかもしれませんが、まとめると以下のようなビジネスルールが識別されました。
- 休暇が申請できるのは（ONLY IF)従業員が在籍している場合だけである
- 休暇残り時間（VacationHours）は0未満にならない
- 期間はいつでも開始日時<=終了日時が成り立つ
- （IF）マネージャがいない申請者ならば（THEN）申請先の上司は人事担当者になる
- 休暇時間は申請期間のうちの申請者の稼動時間である。
なお、あまりにも当たり前のビジネスルールを記述しているとかなり量が増えるので、ビジネス上の仕組みなど重要なものに絞って識別することが実務では重要です。当たり前のものとは業務知識に依存しないもので汎用的なルールで、先ほど識別した「期間はいつでも開始日時<=終了日時が成り立つ」などが該当します。このルールは設計モデルで汎用的な期間クラスを作成したタイミングで識別も含めて組み込むことが可能です。
