概念モデリングの粒度

既存システムの刷新をする場合などは、既存のデータベース設計があってそれをベースを開発を進める場合があります。このようなケースでOOADで開発する場合、データベースをもとに概念モデルや組み立てていく必要があります。しかし、なまじ詳細なテーブル情報があるのでモデルが詳細になり見通しが悪くなる場合があります。これを防ぐためにはより大きなモデリングの粒度を考える必要があるのですが、どのような粒度が良いかが悩みます。

僕は、新規で開発を行う場合の出発点としては概念エンティティ（トップレベルの識別子をもつエンティティ）を使うので、既存のDBがある場合でも概念エンティティをそのまま応用しています。

もし、テーブルがあるのであれば手順的には以下のような３ステップで概念エンティティは簡単に洗い出せます。

1. PKから識別子をすべて洗い出し
2. 識別子からエンティティを識別
3. トップレベルのエンティティか判断

たとえば、PKにEmployeeIDというのがあればEmployee(従業員)エンティティを識別してトップレベルで利用しているか判断します。識別子を洗い出す作業なので基本テーブルのPK部だけを調査するだけですみます。

SQLServerにはAdventureWorksというサンプルデータベースがあるのですが、このテーブル数が約７０個あるのですが、エンティティを抽出すると11個になります。70個のテーブルが配置されたER図にくらべてかなり取り扱いやすいモデルになります。

あとはこの概念エンティティを定義された用語としてビジネスルールの定義やユースケースを記述を進め分析をすすめていけばよいだけです。

ちなみに概念エンティティはAggregateルートに対応するもので、導出項目や検証ロジックのビジネスルールを分析・定義するとそのままドメインモデルになります。