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

モデリング DDD

次はイベント系のエンティティを分析・設計してみる

前回はリソース（マスタ）系の従業員エンティティを対象にしました。今回はイベント（トランザクション）系のエンティティを分析・設計していき最終的にはドメインモデルで実装するようにします。
AdventureWorksのイベント系のエンティティはいくつかありますが、注文販売(SalesOrder)を対象にしてみたいと思います。

注文販売(SalesOrder)を分析する

まずは、前回行った手順と同じように注文販売(SalesOrder)に関係するテーブルを識別してER図に整理します。主要なテーブルは注文販売(ヘッダ)(SalesOrderHeader)と販売注文(明細)(SalesOrderDetail)で親子構造になっています。関連するテーブルも多数あり いくつかは複雑な構造をしているものもありますが、ここでは直接関連を持っているエンティティだけを識別すれば良いので余計なテーブルは除外してできるだけシンプルにします。

このER図からクラス図を作成します。ほぼ同じような構造にマッピングしています。ただ製品_割引（SpecialOfferProduct）のあたりが少し異なっています。製品_割引は特定の製品に利用可能な割引の組み合わせルールを表しているようです。実際、注文販売(明細)（SalesOrderDetail）から製品_割引(SpecialOfferProduct)へFKが張られていて構造制約として利用されています。わざわざ組み合わせルールのテーブルにFKを張るようなことはしたことがなかったので、なかなか面白いアイデアだと思いました。

なお、関連に対して依存矢印を出して制約をつける表現はDDDにあったので愛用しているのですが正式なUML表記ではないんでしょうね。UMLツールでは記述できないので図形の矢印を使って表現しています。