Home
Get Started
実践ガイド
外部仕様設計
バッチ処理仕様設計
UAC 仕様設計
データ仕様設計
インフラ設計
移行計画
テスト方針・計画
開発プロセス・規約
概念データモデル設計
業務要件を正確なデータ構造へ変換し、開発チーム全体で共通のドメイン理解を形成するための概念データモデルを設計します。
🎯 概要
- 目的: システムで扱う業務概念(エンティティ)とその関係性を明確にし、業務要件を正確にデータ構造へ反映することで、開発チーム全体が共通のドメイン理解を持ち、一貫性のあるデータ設計を実現する
- スコープ: 業務ドメインの境界、主要エンティティ、エンティティ間の関連、データ制約・業務ルールをカバーする。物理的なテーブル設計やインデックス設計は対象外
- 推奨する実施タイミング: 通常、基本設計の初期段階で、要件定義で整理された業務フローや画面要件を受けて実施する
- 関連するステークホルダー: システムアーキテクト、データベース設計者、ビジネスアナリスト、プロジェクトマネージャー
📥 重要な前提知識・インプット
- 前提知識: ER図の記法、ドメイン駆動設計(DDD)の基本概念(エンティティ、バリューオブジェクト、集約)、正規化理論、データモデリング手法
- インプット: 要件定義書、業務フロー図、画面設計書、既存システムのデータモデル、業務用語集
📄 成果物の定義
- ドキュメントテンプレート: 📄
[テンプレ]概念データモデル仕様書
- 必須要素: ドメイン構造図、エンティティ一覧、概念ER図、エンティティ詳細定義(属性・制約)、データ制約・業務ルール一覧
✅ 品質基準・レビュー観点
✅ 品質チェックリスト:
| チェック項目 | チェック内容 |
|---|---|
| エンティティの網羅性 | 業務要件で扱う全ての重要な業務概念がエンティティとして定義されている |
| 関連の整合性 | エンティティ間の関連(多重度)が業務ルールと整合している |
| 正規化の適切性 | 適切に正規化され、データの冗長性や更新異常が排除されている |
| 業務ルールの反映 | データ制約や業務ルールが明確に定義され、モデルに反映されている |
| ドメイン境界の明確性 | 各ドメインの責務と境界が明確に定義されている |
👁️🗨️ レビュー観点:
- 業務要件との整合性: 要件定義書や業務フローで定義された業務概念が漏れなくモデル化されているか
- ドメイン専門家の理解: ビジネス側のステークホルダーがモデルを理解でき、業務実態と合致しているか
- 拡張性: 将来の機能追加や業務変更に柔軟に対応できる構造になっているか
- 実装可能性: 物理設計への展開が可能な粒度と構造になっているか
🧪成果物のサンプル
# 概念データモデル
## ドメイン構造
本システムでは、以下のドメイン(業務領域)で情報を扱う。
```mermaid
graph TB
subgraph 会員管理ドメイン
A[会員情報]
B[会員ステータス]
C[会員履歴]
end
subgraph 商品管理ドメイン
D[商品情報]
E[カテゴリ情報]
F[在庫情報]
end
subgraph 注文管理ドメイン
G[注文情報]
H[注文明細]
I[決済情報]
end
A --> G
D --> H
G --> H
G --> I
D --> F
E --> D
```
## ドメイン定義
| ドメイン名 | 責務 | 境界 |
|----------|------|------|
| 会員管理 | 会員の登録、認証、ステータス管理 | 会員の個人情報と権限に関する情報のみを管理 |
| 商品管理 | 商品マスタ、在庫、カテゴリの管理 | 商品の基本情報と在庫状態の管理。価格履歴は含むが販売実績は含まない |
| 注文管理 | 注文受付、決済、配送管理 | 注文から決済完了までの一連のプロセスを管理 |
---
## エンティティ(ドメインモデル)一覧
| No | エンティティ名 | 論理名 | ドメイン | 概要 |
|----|--------------|--------|---------|------|
| 1 | Member | 会員 | 会員管理 | システム利用者の会員情報 |
| 2 | MemberStatus | 会員ステータス | 会員管理 | 会員ランク(BRONZE/SILVER/GOLD/PLATINUM) |
| 3 | Order | 注文 | 注文管理 | 会員が行った注文の基本情報 |
| 4 | OrderItem | 注文明細 | 注文管理 | 注文に含まれる商品と数量 |
| 5 | Product | 商品 | 商品管理 | 販売商品のマスタ情報 |
| 6 | Category | カテゴリ | 商品管理 | 商品分類カテゴリ |
| 7 | Inventory | 在庫 | 商品管理 | 商品の在庫数と状態 |
| 8 | Payment | 決済 | 注文管理 | 注文に対する決済情報 |
---
## 概念ER図
```mermaid
erDiagram
Member ||--o{ Order : "注文する"
Member ||--|| MemberStatus : "持つ"
Order ||--|{ OrderItem : "含む"
OrderItem }o--|| Product : "参照する"
Product }o--|| Category : "属する"
Product ||--|| Inventory : "在庫を持つ"
Order ||--|| Payment : "決済される"
```
---
## 属性一覧(バリューオブジェクト一覧)
| バリューオブジェクト名 | データ型 | 制約 | 説明 |
|-------------------|---------|------|------|
| MemberId | 文字列 | 20文字固定、英数字 | 会員を一意に識別するID |
| Email | 文字列 | RFC5322準拠 | メールアドレス |
| MemberStatusType | 列挙型 | BRONZE/SILVER/GOLD/PLATINUM | 会員ステータス区分 |
| OrderId | 文字列 | 20文字固定、英数字 | 注文を一意に識別するID |
| Money | 数値 | 小数点以下2桁、0以上 | 金額(税込) |
| Quantity | 整数 | 1以上 | 数量 |
| ProductId | 文字列 | 20文字固定、英数字 | 商品を一意に識別するID |
---
## データ制約・業務ルール一覧
| ID | ルール名 | 制約内容 | 対象エンティティ |
|----|---------|---------|---------------|
| BP-001 | 金額非負制約 | 金額項目は0以上でなければならない | Order, OrderItem, Payment |
| BP-002 | 会員ステータス遷移 | ステータスは累計購入金額に基づき自動更新される | Member |
| BP-003 | 在庫引当 | 注文確定時に在庫を引き当て、在庫不足の場合はエラー | Inventory, OrderItem |
| BP-004 | 注文キャンセル制限 | 配送済み(SHIPPED)以降はキャンセル不可 | Order |
| BP-005 | メールアドレス一意性 | 同一メールアドレスで複数会員登録不可 | Member |
--- 🔄 設計の進め方・プロセス
🏗️ プロセス1: ドメイン境界の特定
設計対象:
システムで扱う業務領域(ドメイン)を特定し、各ドメインの責務と境界を明確にする。
具体例:
- ECサイトの場合: 会員管理ドメイン、商品管理ドメイン、注文管理ドメイン、配送管理ドメイン など
- 人事システムの場合: 組織管理ドメイン、従業員管理ドメイン、勤怠管理ドメイン、給与計算ドメイン など
- 各ドメインがどの業務プロセスを担当するか
- ドメイン間でどのような情報をやり取りするか
設計原則:
- 業務の凝集性: 関連性の高い業務概念は同一ドメインにまとめ、異なる業務領域は別ドメインに分離する
- 境界の明確化: ドメイン間の責務を明確にし、境界が曖昧にならないようにする
- 独立性の確保: 各ドメインは独立して理解・変更できるように設計し、ドメイン間の結合度を低く保つ
- ビジネスとの対応: ドメイン分割は組織構造や業務プロセスと整合させ、ステークホルダーが理解しやすい構造にする
文書化の推奨表現:
- ドメイン構造図の作成: システム全体のドメイン構造を視覚的に表現し、ドメイン間の関係性を示す
- ドメイン定義表の整備: 各ドメインの名称、責務、境界を一覧表で明確にする
- ドメイン間インターフェースの記録: ドメイン間でやり取りされる情報を明記する
🏗️ プロセス2: エンティティの抽出と定義
設計対象:
各ドメイン内で扱う主要な業務概念(エンティティ)を抽出し、その属性と識別子を定義する。
具体例:
- 会員管理ドメイン: 会員、会員ステータス、会員履歴
- 注文管理ドメイン: 注文、注文明細、決済
- 各エンティティが持つ属性(名前、メールアドレス、注文日時 など)
- 各エンティティを一意に識別するキー(会員ID、注文ID など)
設計原則:
- 業務概念の忠実な反映: ビジネス用語や業務フローで使われる概念をそのままエンティティとして定義する
- ライフサイクルの同一性: 同じライフサイクルを持つ情報は一つのエンティティにまとめる
- 識別子の一意性: 各エンティティには必ず一意な識別子を持たせる
- 不変性の考慮: 識別子やコア属性は変更されない値を選ぶ
- 適切な粒度: エンティティは大きすぎず小さすぎず、適切な粒度で定義する
文書化の推奨表現:
- エンティティ一覧表の作成: エンティティ名、論理名、所属ドメイン、概要を一覧化する
- エンティティ詳細定義: 各エンティティの属性、データ型、制約、説明を記載する
- 識別子の明記: 各エンティティの主キーとなる属性を明確にする
🏗️ プロセス3: エンティティ間の関連定義
設計対象:
エンティティ間の関係性(関連)を定義し、多重度や関連の種類を明確にする。
具体例:
- 会員と注文: 1人の会員は複数の注文を持つ(1対多)
- 注文と注文明細: 1つの注文は複数の注文明細を持つ(1対多)
- 注文明細と商品: 複数の注文明細が1つの商品を参照する(多対1)
- 会員と会員ステータス: 1人の会員は1つの会員ステータスを持つ(1対1)
設計原則:
- 業務ルールの反映: 関連の多重度は業務ルール(必須/任意、1対1/1対多/多対多)を正確に反映する
- 参照整合性の確保: 参照関係が一貫性を保てるように設計する
- 循環参照の回避: 可能な限りエンティティ間の依存関係を一方向に保ち、循環参照を避ける
- 集約の識別: 強く結合したエンティティ群(集約)を識別し、整合性の境界を明確にする
文書化の推奨表現:
- 概念ER図の作成: エンティティ間の関連を視覚的に表現したER図を作成する(Mermaid、PlantUML等を使用)
- 関連定義表の整備: 関連名、関連元・関連先、多重度、関連の説明を一覧化する
- 集約の明記: 集約ルート(親エンティティ)と集約内の子エンティティを明確にする
🏗️ プロセス4: データ制約・業務ルールの定義
設計対象:
エンティティや属性に対する制約条件と業務ルールを明確に定義する。
具体例:
- 金額は0以上でなければならない(非負制約)
- メールアドレスは一意でなければならない(一意性制約)
- 注文確定時に在庫を引き当て、在庫不足の場合はエラーとする(業務ルール)
- 配送済み以降は注文キャンセル不可(状態遷移制約)
- 会員ステータスは累計購入金額に基づき自動更新される(派生ルール)
設計原則:
- 明示的な定義: 暗黙の前提とせず、全ての制約と業務ルールを明示的に文書化する
- 実装可能性: データベース制約、アプリケーションロジック、どちらで実装するかを考慮した制約定義を行う
- トレーサビリティ: 各制約が要件定義のどの業務ルールに対応するかを明確にする
- 例外処理の考慮: ルールに対する例外ケースがあれば、それも合わせて定義する
文書化の推奨表現:
- データ制約一覧表の作成: 制約ID、制約名、制約内容、対象エンティティ/属性を一覧化する
- 業務ルール一覧表の作成: ルールID、ルール名、ルール内容、適用条件を一覧化する
- 状態遷移図の作成: エンティティの状態遷移がある場合は状態遷移図で視覚化する
- バリデーションルールの明記: 必須/任意、文字数制限、形式チェック、範囲チェック等を具体的に記載する
🚨 よくある失敗と予防策
🚧 実例収集後、追記予定
📚 参考資料・関連リンク
- 参考文献: 『ドメイン駆動設計』(Eric Evans)、『実践ドメイン駆動設計』(Vaughn Vernon)、『データモデリングでドメインを駆動する』、『楽々ERDレッスン』
- 関連する他のガイド: 論理データモデル設計ガイド、物理データベース設計ガイド、API設計ガイド
- ツール・テンプレート: Mermaid(ER図)、PlantUML、draw.io、ERMaster、A5:SQL Mk-2
テンプレートサイト: 📄テンプレート集