AdventureWorksをモデリングしてDDDしながらドメインモデルで実装してみる（３）

前回は、従業員（Employee）エンティティに関連するテーブルを分析して、静的な構造を識別しました。さらに役立つモデルにするためにビジネスルールを記述可能になるように分析モデルをリッチ化します。

エンティティのデータを確認する

まずは、今回ターゲットの従業員（Employee）エンティティについて考えてみます。エンティティの分析を行う場合、該当データを利用している画面の表示内容を調べたりしますが、より手間をかけない方法はエンティティの台帳をExcelなどで作成して利用する方法です。
今回は既にデータもそろっているので、Employeeメインテーブルに保持されているデータを台帳に見立てて確認できます。

このテーブル構造やデータを眺めるだけでもいろいろ想像できそうですね。例えば、従業員の入社日（HireDate）から勤続年数を導出したり、部下の一覧取得なんかが想像できます。
当たり前すぎるレベルかもしれませんがこれも立派なビジネスルールですね。「勤続年数」というビジネス用語が定義すると、より複雑なビジネスルールを定義し易くなります。例えば「退職金計算」ルールを定義するのに「勤続年数」を利用することができます。

この段階でエンティティ上で明確に利用されるビジネス用語があればエンティティに付与します。それは特定のシステム機能に依存するものではなくエンティティが持っている本質的な機能でさまざまなシナリオで利用されることが予想されます。重要なビジネス用語ということです。

もちろん、台帳レベルで識別できないビジネス用語やより複雑なビジネスルールもあります。それらの分析をこれから考えていきます。

ユーザ機能を定義する

複雑なビジネスルールを考えていくのですが、その前にその根拠になるエンティティの使用シナリオを考える必要があります。通常はユースケースなどのシステムの機能仕様があってそれを元に分析することで使用シナリオがわかります。今回は具体的な機能仕様はないので使用シナリオを想像する必要があります。
機能定義としてはユースケースが一般的で悪くはないのですが、ここではもう少し軽めのユーザ機能というものを利用して機能定義をしていきます。

ユーザ機能はユーザのアクション（オペレーション）ごとの機能でユーザが使用する用語で表現できる最小の機能です。「○○を△△する／○○を◇◇に△△する」で表現されます。
例)
・製品を購入する
・製品の納期を計算する

上記を見てもわかるように○○や◇◇にはエンティティや情報が入ります。逆に考えると、エンティティからユーザ機能を識別または推測することができます。たとえば、今回ターゲットである「従業員」に対してユーザ機能を推測するといろいろ出すことができます。

・従業員を登録する
・従業員の給与を計算する
・従業員の現在部署を取得する
・従業員を部署に配属する
・従業員のシフトを変更する