概念モデリング再入門 + DDD

ULS Powered byCopyright © 2015 UL Systems, Inc. All rights reserved. Proprietary & Confidential
概念モデリング再入門 + DDD
～今さら聞けない人のための基礎講座～
ウルシステムズ株式会社
河野正幸
情報システム部門を「強く」し、次世代リーダを育成する

ULS Copyright © 2015 UL Systems, Inc. All rights reserved. Proprietary & Confidential Powered by
概念モデリングやってますか？
 システム化の対象業務や問題に対して深く本質的な理解を得る
上で概念モデリングは非常に有効な活動
 河野の場合は概念モデリング抜きにシステム化の検討をすることはもは
や考えられないほど、自分の中に定着している
 DDD(ドメイン駆動設計)に取り組むのなら必須でしょう！
 もしやっていない人がいるのなら、本当にもったいない。ぜひ一
度やってみてほしい
 まずは始めてみることが大切。始める前から腰が引けている人が多いと
感じる
 プロジェクトの皆で一緒に始めようとするから敷居が高くなる。まずは自分
一人でこっそりと描くところから始めよう
 本日の私の目標は「明日から概念モデリングやってみようかな」
という気になってもらうこと

本日の内容
自分一人でこっそりと概念モデリングをスタートする際に
この位知っておけば十分でしょうという
1. スタートする上での最低限の基礎知識
始めてみたもののうまく描けないという人のための
2. 要領良くモデルを描くために知っておくと良いこと
DDDに興味がある人のために
3. ドメインモデル設計のポイント
この3点を今日はお話しします

１．最低限の基礎知識

UMLで描いた概念モデルの例
概念名
属性
概念の種類を表す線
概念同士の
関連を表す線
関連の
多重度
関連の
役割名
注釈(ノート)
自動車ディーラーの見積業務
重要な概念は属性ではなくクラスとして記述する
関連の多重度は絶対に記述する
注釈(ノート)はできるだけ多く、詳しく記述する

概念モデリングの手順
1. テーマの選定
2. 概念の識別
3. 属性の定義
4. 関係の定義
6

１．テーマの選定
 何をテーマに概念モデルを描くのかをまず決める
 テーマの広さによってモデルの目的や詳細度は変えた方が良
い
 全体概要モデル
 会社全体を対象にしたり、販売管理・生産管理といった広い業務領域を対象に
全体像をざっくりと把握するために描く
 詳細な情報は切り捨てて主要な概念だけで全体像をわかりやすく表現する
 個別詳細モデル
 見積、受注、出荷、請求などビジネスユースケース位の単位で業務の詳細を正
確に把握するために描く
 業務の詳細理解のために必要な情報は漏れなく記述する。最終的には論理デ
ータモデルの元ネタとできるレベルまで詳細化する
7

２．概念の識別
 以下の概念分類を参考に選定したテーマに存在する概念を識別する
8
大分類説明小分類説明
リソース経営資源に関
連する概念
パーティ・他のパーティと契約を締結してビジネスを遂行する能力を有する「法人」や「個人」に関わる概念
・法人や個人が特定の取引に参加する時のロール（役割）に着目して概念を識別する
・顧客、仕入先、商社、メーカー、配送業者、委託加工業者など
もの・ビジネスで消費したり生産したりする「もの」に関わる概念
・商品、副資材、原材料、生産設備など
場所・「場所」に関わる概念
・在庫場所、店舗、倉庫、配送先、保管棚など
ルール
ポリシー
・ビジネスを遂行する上での「ポリシー」や「ルール」に関わる諸々の概念
・決済方法、受渡方法、契約、為替レート、工程、配送ルートなど
イベントビジネスにおい
て人やものや
場所といったリ
ソースが相互
作用して引き起
こされるビジネ
ス上の事象
通常
イベント
・ビジネスの目標を達成するための重要なイベント。口座型データストアを増減する。
・受注、出荷指示、出荷、販売、請求、発注、入荷、入荷案内、仕入、支払、加工/梱包指示、加工/梱
包実績など
異動
イベント
・リソースのライフサイクルを通じた重要な状態変化の履歴を表し、長期間にわたって保存する必要が
あるイベント
・単価改訂、人事異動、設計変更、設備修理など
データ
ストア
ビジネスを円滑
に遂行する上
で把握しておく
ことが必要な情
報
口座型
データストア
・経営資源の現状を示す、常時増加や減少を繰り返す口座的な情報を記録する概念
・商品在庫、銀行口座、受注残高、勘定口座など
B/S型
データストア
・リソースや口座型データストアの特定時点（日末、月末、期末、年度末など）の状態を記録する概念
・貸借対照表(B/S: Balance Sheet)のように時系列で推移を見る目的で使用する
・在庫、資産、債権債務などの特定時点での記録
P/L型
データストア
・生産高や売上高などのイベントをカテゴリ（製品、場所、期間、顧客など）ごとに要約して記録する概
念
・損益計算書(P/L: Profit and Loss Statement)のようにある期間での業績を評価する目的で使用する
・月次商品別売上高や部門別間接費などの記録

３．属性の定義
 概念の特性をよく表している主要な属性を定義する（名称、日
付、数量、金額など）
 コードや区分などで表現される情報はそれ自体が独立した概
念になることが多い。こういったものはなるべくクラスとして表現
する
 データベースの設計をしているわけではないので、すべての属
性をこの時点で詳細に洗い出す必要はない（後の論理データ
モデル設計で実施すればよい）
 概念のアイデンティティを把握する上で主キーは意識した方が
良い。ナチュラルキーの主キーに含まれる属性を定義して主キ
ーを把握しておく
9

４．関係の定義
 概念同士の関係とその多重度を定義する。多重度はビジネス
ルールを示している場合も多いので必ず定義する
 種類を明示したいものについて「汎化」関係で表現する
 基本的には「関連（アソシエーション)」「汎化」の2種類の関係だ
けで十分概念モデルは表現できる
 「関連（アソシエーション）」のうち「集約（アグリゲーション）」「複
合（コンポジション）」まで細かく識別することは、概念のライフ
サイクルを意識してより深く概念構造を理解するためには有用
だが、無理やり使おうとしてかえって混乱することも多いので割
愛してよい
10

２．要領良くモデルを描くために

概念モデリングが習慣づかない人のNG行動(1)
 理論武装してから始めようとする
 UMLなどの表記法やモデリングのやり方を教科書等できっちりと理論武装してからでな
いと始められないと思う人は、上手に描きたいという気持ちが強すぎてなかなか始められ
れない。とにかく下手でも良いから描いてみる。そのためには最初に余計な知識は無い
方が良い
 自分の描いたモデルが正解かどうかにこだわり過ぎる
 世の中のどこを探しても自分の描いたモデルの正解は載っていない。同じ業務を対象に
しても前提とするルールが異なれば異なるモデルになるのが当たり前
 いわゆる教科書に載っているようなリファレンスモデルはあくまでも参考情報であって、そ
のモデルの置く前提と自分が対象としているものの前提が異なれば違うモデルになる。そ
れを「どうして自分のモデルは教科書(=正解と思い込んでいる)と違うのだろう？」と悶々
と悩んでも答えは永遠に出ない。自分が理解した内容で描いたモデルがその問題の正解
のモデルなのだと割り切るべき
12
教科書に載っていたモデル
自分で描いてみたモデル
1回の注文を分納すること
を想定
注文が無くても出荷は発生
する。例えば工場から倉庫
への移動
1回の注文を必ず1度の出
荷で満たすことを想定
注文が無ければ出荷は絶
対にしない
注文出荷
注文出荷
0..1 0..*
1 0..1

 うまくモデルが描けなくて途中で投げ出す
 「知らないことはモデルには描けない」。この単純な事実を受け入れて「自分が理解できて
いないことがわかって良かった」と前向きに転嫁して必要な知識・情報を積極的に仕入れ
る。知らないことは恥ずかしいことではない
 河野が新しいテーマで概念モデルを始める時には以下の2つの知識をまず仕入れること
にしている。前提知識としてこの2つがある程度理解できていれば、比較的スムーズにモ
デルを描くことができる
 対象企業が扱っている商品(製品、サービス)
 対象企業を取り巻くパーティ(自社組織、取引先)
13
商品
新車販売
中古車販売
点検・修理
用品販売
保険販売
パーティ
自社部門
取引先
本社
店舗
顧客
サプライヤ
個人顧客
法人顧客
自動車メーカー
用品メーカー
修理工場
損保会社
クレジット会社
自動車ディーラーの商品とパーティ

 最初から綺麗な最終形を描こうとする
 あるテーマで最終モデルを作成するまで、河野の場合は以下の3段階くらいのモデルを
描いてみる
1. 全体をざくっと把握するための概要のモデル
2. 業務を深く理解する目的で抽象化をせずになるべく詳細に表現したモデル
3. 業務を深く理解した上でデータ設計につなげるために抽象化をして整理したモデル（最終形）
 世の中で紹介されているモデルは最終形がほとんどなので、最初からそういう内容のモ
デルを描こうとしがちだが、これだと業務や問題を深く理解できないこともある。初期の2
段階のモデルをきちんと描く方が実は業務がよく理解できる
14
部品表の最終モデル
品目
- 品目コード
- 名称
品目構成
- 員数
- 適用期間
品目種別品目構成種別
完成品、ユニット部品、末端部品等
の品目の種別
品目の構成の親子の組み合わせの
ルールに応じて設定する構成の種別
*
+親品目
1
*
+子品目
1
1
*
1
*
部品表理解のための初期概要モデル
完成品ユニット部品末端部品
完成品-ユニット部品
構成
完成品-末端部品
構成
ユニット部品間
構成
ユニット部品-末端部
品構成*
+親 1
*
+子 1+親 1
* *
+子 1
*
+親 1
*
+子 1 +親 1
* *
+子 1
抽象化

概念モデルを要領良く描くコツ(1)
 まずイベントを見つけ5W3Hを考えてざくっとモデルを描く
 イベント概念は通常5W3Hを表すので、この観点から整理することでイベントに関わる主要なリ
ソースに関する情報を洗い出せる。構造は後から精査すれば良い。とにかくモデルにしてみる
ことが肝要
15
例：「受注」というイベント概念の5W3H
When(いつ、いつまでに) ：受注日、希望納期
Who（誰が) ：営業担当者
Whom(誰に) ：顧客、商社
What(何を) ：商品
Where(どこに) ：納品場所
How(どうやって) ：決済条件
How much(どれだけ) ：金額
How many(どれだけ) ：数量
受注
- 受注番号
- 受注日
- 希望納期
- 数量
- 金額
商品
顧客
商社
納品場所
決済条件
営業担当者
1
*
*1
*0..1
* 1
* 1
*
1
受注
- 受注番号
- 受注日
受注明細
- 数量
- 単価
- 希望納期
商品
取引先
商社が商流に入るケース
については請求先が商社
になる。それ以外は販売
先と請求先は同じ取引先
になる
社員
納品場所
取引先毎にあらかじめ納
品場所を複数設定してお
き、受注時に選択できるよ
うにする
決済条件
決済条件はあらかじめ取
引先との基本契約で一意
に決まるので受注単位で
保持する必要はない
1
*
* 1
*
+販売先
1..*
*
+請求先
1
+受注担当者
1*
1
*
*1
1
*
１．5W3Hでまずざくっと描いてみる
２．業務をよく分析してモデルを洗練する

 双方向で関連を精査して適切な概念構造を導き出す
 片方から見ると妥当に思えても逆方向から見ると結果的に多対多関連になることがある
 多対多関連は放置せず、その2つの概念の間に存在する関連を管理する概念をきちんと
導き出すとすっきりと整理できる
16
２．注文から商品の関連を考える
1件の注文で複数の商品を注文できる
だから多重度は多になる
１．商品から注文の関連を考える
ある商品は色々な人から注文できる
だから多重度は多になる
３．多対多関連になってしまったので解決する
注文は複数の商品明細を保持し、各明細が
注文対象の商品を知っていると考えると解決する
商品はマスタなので独立に存在できる
注文明細は固有の注文に属する情報だと
切り分けるとすっきりする
注文商品
*
注文商品
**
注文明細商品
注文
1
*
*1

 双方向で関連を精査して適切な概念構造を導き出す(の続き)
 前頁の例とは異なり、最初はイベントに従属する情報だと思っていたものが、逆方向から
眺めるとマスタとして別概念を切り出した方が良いと気付く場合もある
17
１．検査実績から不良理由明細の関連を考える
1回の検査で複数の不良理由(割れ、変形、
サビなど)が発見される可能性があるので、
検査理由明細として複数の理由が記録できる
ようにした
２．不良理由明細から検査実績への関連を考える
不良理由の記録が各検査実績に含まれる
情報だと最初は考えたので一つの検査実績に
関連すると考えた
３．不良理由という観点から関連を見直してみた
視点を変えて不良理由を条件に該当する
検査実績を全て調査したいという要求があると
考えてみた
この場合、不良理由は独立して存在する
概念として考えた方がその要求を満たす
モデルとしてはふさわしいと考えて見直した
検査実績検査実績不良理由明細
*
検査実績検査実績不良理由明細
1
*
検査実績
検査実績不良理由明細不良理由
1
*
* 1

 2つの概念間に別の種類の複数の関連が無いかを精査してみる
 あるモノに対していくつかのイベントが発生する場合は、イベント側の多重度は多になる。
基本的にはそれで問題が無いが、情報をどう活用したいかという観点で関連を深堀りし
てみると「過去の履歴を参照する」「最新の状態を参照する」という2つの用途が求められ
ることが多い。こういったこともモデルにきちんと表現しておくとわかりやすくなる
18
１．製造ロットは複数工程の作業実績を
持つので多重度を多とした
２．履歴だけではなく最新の仕掛工程も
知りたいので関連を2種類定義した
製造ロット
品目
工程順序
工程実績
製造ロットが前の工程の
作業を完了した時点で工
程マスタを参照して、次の
仕掛工程の情報を追加で
作成する
実際に該当工程順序で作
業が行われた時に実績を
作成する
1
*
1
*
1
0..1
製造ロット
品目
工程順序
工程実績
過去の工程実績を参照す
るために使用する
最新の仕掛工程を参照す
るために使用する
1
0..1
1
*
1
+履歴 *
1
+仕掛工程0..1

 概念同士の関連においてロールを意識してうまく表現する。ただしシンプルに！
 概念同士の関連がただ一つしか無い場合にはその関連の意味は明確であるが、複数の関連が存在するケー
スもある。その場合にはその関連において概念がどのようなロールを担うのかをモデルに記述することで的確
に表現することが可能になる
 業務を理解する目的とロールそのものをどう管理するかという目的が混同するとわかりづらくなるので目的を
切り分けてシンプルにモデルを描く
19
１．自動車の見積には3種類の顧客情報が必要２．販売契約には3種類の取引先が参加する
見積顧客
*
+契約者
1
*
+使用者
1
*
+紹介者
0..1
販売契約
販売先
請求先
注文者
取引先
*1
*1
*1
＊ある一つの取引先が複数のロールを取り得る場合（普通はそう）
厳密にUMLの規則に従うと汎化では表現できない。でもわかりやすけりゃ
これでもいいんじゃないというのが河野の考え方
３．取引先のロールを厳密に管理することを意図し
しかも販売契約との関連も表現してみたモデル
＊販売契約という概念を理解することが目的なら、取引先ロールの
部分はやり過ぎ。1のモデルと同じようにシンプルに関連を直接
張ってロール名を記述するのが一番分かり易いと思う
取引先
取引先ロール販売契約
取引先ロール種別注文者、販売先、請求先、出荷先、
仕入先等の取引先がビジネスに参
加する際の役割(ロール)を定義す
る。どの取引先がどのロールを取り
得るかのチェックがしたいので、そ
のルールを定義する概念
1 *
*
+注文者
1
+販売先
1 *
*
+請求先
1
1
*

 モノに関連している概念を考える場合、それがモノの「種類」を扱っているのか「現品
」を扱っているのかを精査することで正しい理解が得られる
 モノの種類を指定して行う仕事と、現品を直接扱う仕事とをしっかりと区別しないと業務を
正しく理解できないリスクが高いので注意する
20
１．一見正しく思えるが間違った
理解をしているモデル
２．モノの種類と現品をきちんと区別して
理解しているモデル
注文(新車)
車
注文(中古車)
1
*
1
*
注文(新車)
車種
- 車種コード
- 主要諸元
注文(中古車)
車両
- VIN
- 年式
- 車検年月
モノの種類を表す概念現品(現実に存在する個体)を表す概念
新車はまだ存在しない車
両の種類を指定して注文
する。ただし、USのように
新車も店頭在庫から販売
する場合は中古車と同じ
モデルになる
中古車は既に市場に流通
している特定の車両を指
定して注文する
納車(新車&中古車)
納車は既に存在する特定
の車両をターゲットに実施
するので新車/中古車の
違いはない
1
+履歴 *
10..11 0..1
1
*
1 *
1
*

概念モデルを要領良く描くコツ(7)-(1)
 ある仕事を遂行するためのルールや手順・ポリシーなどを管理する「知識レベル」の
概念と、それらを適用して実際に業務を実行する際のオペレーションを管理する「操
作レベル」の概念は混同しがちなので、しっかりと精査して切り分ける
 マスタ的な情報と、そのマスタを適用して特定のオペレーションを制御するために必要な
情報が混同すると、一見正しいモデルに見えて細部では色々と矛盾があるモデルになっ
ている可能性があるので注意する
 「知識レベル」「操作レベル」という言葉はファウラーがアナリシスパターンで使用した
21
１．「知識レベル」「操作レベル」が切り分けられていないモデル
航空便
- 便名
- 運航日
- 出発予定時刻
- 到着予定時刻
空港
予約
- 予約番号
予約便明細
顧客予約搭乗者明細
機材
座席
+出発空港
1 *
*
+到着空港
1
1
*
*
+搭乗者
1
*1
1
1..*
*
1
1
1..*
*0..1
*
+予約者 1
このあたりが整理
できていない

 前頁から続く
22
航路
- 便名
- 出発予定時刻
- 到着予定時刻
空港
予約
- 予約番号
予約便明細
顧客予約搭乗者明細
機種マスタ
座席マスタ
航空便
- 運航日
予約機種
予約座席
実機材
1 *
*
+到着空港
1
+出発空港
1 *
1
*
*
+予約者 1
*
+搭乗者
1
1
*
1 *
1
0..1
1
*
1 *
*0..1
1
*
0..1
*
1
*
２．「知識レベル」「操作レベル」を切り分けて整理したモデル
知識レベルの世界操作レベルの世界元々一つだった概
念を知識レベルと
操作レベルに分割
するとすっきりした

 口座型データストア(銀行口座、商品在庫、受注残など)は銀行口座における「預金
通帳」に相当する受払の記録を概念として出し、それと残高の増減をもたらした業務
イベントとの関連で表現するとすっきり表現できる
 口座型データストアと増減の源泉となった業務イベントをどう関連づけるかで迷いがち
 「預金通帳」的な汎用的な受払の記録の概念を業務イベントと在庫の間に挟むことで、固
有の業務取引の情報管理と汎用的な口座管理とをうまく紐づけて表現できる
 このモデルはファウラーのアナリシスパターンでは「勘定パターン」と呼ばれているもの。
業務イベントによって残高が増減するような口座をモデル化する時にはほぼこのパターン
が適用できるので覚えておくと使い道が多い
23
１．業務イベントと在庫が遠くてしっくりこないモデル
受注明細
商品
場所別商品在庫
出荷明細発注明細入荷明細
生産実績在庫移動実績
1
*
1 0..* 10..*
1
*
1
*
1
*
1
*

24
２．業務イベントと在庫を無理やり関連づけてはみたが、まだすっきりしないモデル
受注明細
商品
出荷明細発注明細入荷明細
生産実績在庫移動実績
1
*
*
減らす
1
*
増やす
1
*
減らす
1
10..*
1
*
1
*
1
*
1 0..*
1
*
1
増やす
*
*
増やす
1

商品
在庫受払実績
生産実績
業務イベント
入荷実績
1つの業務イベントで受入と
払出が同時に発生する場合
には多重度が2になる
受入イベント
受入&払出イベント
払出イベント
在庫移動実績
出荷実績
発注明細
受注明細
銀行口座で言うと「預金通
帳」の位置づけの概念。
口座の残高の増減を全て
記録しておく
口座の残高の増減をもた
らした源泉となった取引
（イベント）の記録
在庫場所
1
*
*1
1 *
1 1..2
1
*
1
*
*
1
25
３．「勘定パターン」を適用して汎用的な口座情報管理と業務イベント毎に固有な業務取引情報管理を
切り分けて、その間の関連をすっきりと表現したモデル
このような形で業務イベント管理と在庫管理の間に
きちんと境界を設けておくと、新しい業務イベント
（例えば、棚卸結果にもとづく在庫廃棄のイベント）
が増えても在庫管理の構造に影響を与えない

概念モデリング最後に
 つべこべ考えずまずは描いてみましょう。上手い下手を気にせ
ず、数をこなすことで自然と上手になります。ツールも不要です。
紙とペンだけあればいつでもスタートできます
 慣れてきたらその問題をよく理解している人に見せて、理解の誤
りや情報の過不足を指摘してもらいましょう。それが習慣づくとコ
ミュニケーションの質が上がってくるのが実感できると思います
 問題の本質を理解するための概念モデルとデータ設計のための
概念モデルは分けて考えると良いでしょう。前者の概念モデルで
問題を十分理解した上で、システムの都合を考慮した後者の概
念モデルを作成しましょう

３．（おまけ）
ドメインモデル設計のポイント

Why DDD?
 DRY(Don’t Repeat Yourself)な構造にするために一番適し
ているから。以上！
 ファウラーのPofEAA(Pattern of Enterprise Application
Architecture)に紹介されている以下の3つのパターンのうち、もっとも
DRYな構造が実現しやすいと考えている
 トランザクションスクリプト(Transaction Script)
 テーブルモジュール(Table Module)
 ドメインモデル(Domain Model)
 DDDは基本的には上記のドメインモデルパターンをベースにしているため、
ビジネスロジックの置き場所を明確に決めやすい。結果的に同じロジックを重
複して別の場所に書いてしまうことを防ぎやすい

DDDのポイント：右へ！もっと右へ！
 DDDのポイントはドメイン層の中のなるべく右側の責務のクラスに多くのメソ
ッドを配置するように考えて設計すること。以上！
 EntityとValueObjectになるべくビジネスロジックを置くようにして、その2つ
に書けないロジックのみDomainServiceに置くと考えることが重要
 でも、DomainServiceに色々書きたくなっちゃうよね？どうしたら良い？
29
プレゼンテーション層アプリケーション層ドメイン層
インフラストラクチャ層
DDDをベースとしたアーキテクチャの例
Application
Service
Domain
Service
Entity
Value
Object
RepositoryFactory

GRASPを意識して設計してみよう！
30
Entity, Value Object
Entity(Aggregation)
Application Service
Domain Service
 GRASP(General Responsibility Assignment Software Patterns)
– クラスの責務配置の基本原則。これを理解しておく必要がある
– クレーグ・ラーマンが「実践UML」という著書で紹介している正式には
Information Expert

Value Objectを積極的に活用してみる
 品目コード(10桁)の頭一桁で「規格品」「専用品」の判定をしなければならな
いとする
 品目コードをString型で定義すると判定が必要な都度、substringの関数な
どで頭一桁を切り出して判定するようなコードを書く必要がある
 品目コードをユーザ定義型のクラス(Value Object)にしてis規格品()とかis
専用品()というメソッドで判定させるようにするとsubstringでいちいち値を判
定するようなコードを書かなくても済む。また「規格品」には元々”1”の値を割
り当てていたが桁数が不足したために”3”も規格品の扱いにしたくなったとし
ても、品目コードValueObjectクラスだけを修正すれば対応できる
 品目コードのような項目は色々なEntityの属性として利用される。各Entity
のメソッドとして判定メソッドを作成しても良いが、利用するEntityの数だけ同
じようなコードを重複して書くことになる。このような使われ方をする情報項目
は基本(プリミティブ)型ではなくユーザ定義型としてのValue Objectとしてク
ラス化しておいた方が何かと便利
31

Entityになるべく多くの仕事をさせろ(1)
 Entityに属性とその属性のgetter, setterしか持たせないような設計をして
いないか？（ただのデータの入れ物）
 Entityこそドメイン層の主役であり、多くのビジネスロジックの実行を担うべき
スタープレイヤーである。 Entityにろくな仕事をさせていないモデルは「ドメイ
ン欠乏症」、つまり真の意味でのDDDとはいえない
 じゃあEntityにどういう仕事を任せるべきなのか？
32

33
注文管理のEntityクラス注文
- 注文番号
- 注文日
- 受注担当者コード
- 顧客コード
- 注文ステータス (受理, 受注済)
+ 注文明細登録(明細番号, 商品コード, 単価, 数量)
- get注文明細Entity(明細番号)
- getAll注文明細Entity()
+ 受注確認()
+ 注文数量変更(明細番号, 数量)
+ 注文明細削除(明細番号)
+ 注文削除()
- get顧客マスタEntity()
+ get顧客名()
- get担当者マスタEntity()
+ get担当者名()
+ get商品コード(明細番号)
+ get商品名(明細番号)
+ calc明細金額(明細番号)
+ calc合計金額()
+ is受理()
+ is受注()
+ is一部出荷済()
+ is全部出荷済()
+ is数量変更可能(明細番号)
+ is明細削除可能(明細番号)
+ is注文削除完了()
顧客マスタ
- 顧客コード
- 顧客名
- 性別
- 住所
担当者マスタ
- 担当者コード
- 担当者名
注文明細
- 注文番号
- 注文明細番号
- 商品コード
- 単価
- 数量
- 出荷フラグ
- get商品マスタEntity()
+ get商品名()
+ calc金額()
+ is出荷済()
+ 数量変更(数量)
商品マスタ
- 商品コード
- 商品名* 1
1..*
1
*1 * 1

 Entityを利用したい人（クラス）たちが、なるべく”Don’t talk to strangers.”な環境で過ごせる
ようなインタフェースを提供してあげよう。次頁の例のように注文番号と明細番号位を知っている
人(注文コントローラクラス)はその情報を元に「注文Entity」だけ取得すれば、その背後のドメイ
ンクラスの構造を知らなくても「注文Entity」に何でも頼めるようにしてあげる
 上記のように「なるべく少ない情報・知識でなるべく多くの仕事をさせる」ために、エントリポイントと
なるクラスから関連のある背後のクラスに処理をどんどん委譲して多くの仕事をこなせるように考
えて設計する
34
注文コントローラ注文
注文明細
商品マスタ
明細番号1番の商品名称を取得する
1.注文Entityから明細番号1番の注文明細Entityを取得する
2.取得した注文明細Entityから商品マスタEntityを取得する
3.取得した商品マスタEntityから商品名を取得する
注文検索UI
1.get注文明細Entity(明細番号)
2.get商品マスタEntity()
3.get商品名()
注文明細検索(注文番号, 明細番号)
注文コントローラが3つのクラスに話しかけている例

 前頁の続き
 GRASPでいうところの”Information Expert”としての各Entityクラスがそれぞれの責務
を連携して実現することでクライアントの要求を満たす
 注文EntityがDDDでいうところのAggregationの役割で注文情報管理の単一のエントリ
ポイントになることで”Don’t talk to strangers.”な環境をクライアントに提供する
35
注文コントローラはただ1つのクラスにしか話しかけていない例
注文コントローラ注文
注文明細商品マスタ
注文検索UI
明細番号1番の商品名称を取得する
1.注文Entityから明細番号1番の商品名を取得する
　1.1.注文Entityが明細番号1番の注文明細Entityを取得する
　1.2.取得した注文明細Entityから商品名を取得する
　　1.2.1注文明細Entityが商品マスタEntityを取得する
　　1.2.2.取得した商品マスタEntityから商品名を取得する
1.get商品名(明細番号)
1.1.get注文明細Entity(明細番号)
1.2.get商品名()
1.2.1.get商品マスタEntity()
1.2.2.get商品名()
注文明細検索(注文番号, 明細番号)

 クラスの属性の値を単独で編集できるsetterは作らない（公開しない）
 クラスの状態の変更はビジネス上の何らかの意味のあるイベントに対して行われるはず。それを意識して属性
値を変更するメソッドを作る
 以下の例では、注文コントローラが自分で注文明細Entityを取得してそのオブジェクトのsetterを使って数量を
変更するのではなく、GRASPでいうところの”Creator”の役割を果たしている注文Entityの提供する注文数量
変更()というメソッドを通じて、最終的には注文明細Entityの数量変更()で数量を変更している
36
Entityに単独属性のsetterではなく業務上意味のある単位の更新メソッドを提供させる例
注文変更UI 注文コントローラ注文
注文明細
明細番号1番の注文明細の数量を変更する
1.注文コントローラが注文Entityに注文数量変更を依頼する
　1.1.注文Entityは当該注文変更を受け付け可能かをチェックする
　　1.1.1.注文Entityが全部出荷済で完了しているかをチェックする(全部出荷済なら変更不可)
　　1.1.1.注文Entityが明細番号1番の注文明細Entityを取得する
　　1.1.3.注文明細Entityが自分が既に出荷済であるかどうかをチェックする（出荷済なら変更不可)
　[上記で数量変更可能な場合以下を実施する]
　1.2.注文Entityが明細番号1番の注文明細Entityを取得する
　1.3.注文Entityが注文明細Entityに数量変更を依頼する
　　1.3.1.注文明細Entityが自分が既に出荷済であるかどうかをチェックする（出荷済なら変更不可)
　　[上記で未出荷の場合以下を実施する]
　　1.3.2.注文明細Entityが数量を編集する
　　1.3.3.注文明細Entityが自分をupdateする
注文変更(注文番号, 明細番号, 数量) 1.注文数量変更(明細番号, 数量)
1.1.is数量変更可能(明細番号)
1.1.1.is全部出荷済()
1.1.3.is出荷済()
1.1.2.get注文明細Entity(明細番号)
[Trueの場合]:1.2.get注文明細Entity(明細番号)
1.3.数量変更(数量)
1.3.1.is出荷済()
[Falseの場合]:1.3.2.setValue(数量)
1.3.3.update()

概念モデリング再入門 + DDD

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 概念モデリング再入門 + DDD

Similar to 概念モデリング再入門 + DDD (20)

概念モデリング再入門 + DDD