-
Notifications
You must be signed in to change notification settings - Fork 5
vol8_20140622
nyanp edited this page Jul 9, 2014
·
2 revisions
- 日時：2014/06/22 14:00 - 17:00
- 場所：市民交流センターなにわ 103号室
- 範囲：第５章 ソフトウェアで表現されたモデル - 「サービスと隔離されたドメイン層」
- 方法：数分間黙読後、グループでディスカッション
- レポート担当 nomi(@nyanp)
- 「ある区別」とは何か？ … エンティティ・値オブジェクト・サービス 設計の原則
- 「関連を設計して、無駄をなくす」(p.79)
- 関連を絞る、ＤＢの正規化っぽい
- コンテキストが無いと制約をかけられない。もともとの関係は双方向でも、システム要求によってそれぞれに絞っていく
- 関連を適切に見出すにはどうすればよいか？
- いきなりすべてのエンティティを見出すのは難しい。上流でエンティティを見出して、モデリングの過程で絞っている
- DDD外で言うエンティティとの違い。
- エンティティという言葉の意味はＤＢの意味とは違いそう
- 限定子を使うことある？ 上流設計では必ず使う。has-a, has-many関係を区別する
- 連続性ってなに？ → オブジェクトにはライフサイクルがある。時間がかかっても同じものであるということが連続性
- データモデリング分野で使われているエンティティと同じ意味？
- データモデリング分野でのエンティティ：管理対象となるもの 人・モノ・イベント
- 意味合いは大きく違ってなさそう
- なぜエンティティという言葉を使っている？
- Ｅ－Ｒ図っぽい(p.92)
- エンティティという言葉、.NET,Javaにもある言葉。
- 参照オブジェクト：ＩＤによってリファレンス可能なもの。
- データモデリング分野でのエンティティ：管理対象となるもの 人・モノ・イベント
- エンティティの別名が参照オブジェクトなのはなぜ？
- 参照オブジェクトと値オブジェクト、対比関係になっているの？
- 少し意味合いが異なりそう。「参照」は実装の話というより、リファレンス可能なオブジェクトという意味。
- "RASIS"のうちI(完全性)と同一性、似た感じの言葉
- 同一性・連続性 画面で入力したユーザー情報をどう使うか？
- DBからデータを取ってきてIDを生で使うのが駄目なのか？オブジェクトとして扱うのか
- 実装上のテクニックの問題。エンティティと値をDTO 実装上のテクニックとしてはそれが普通になってきている(Railsなど)。パフォーマンス上の理由で値だけ取ってくるような決定もありうる
- エンティティを区別するほうがモデリング上有用
- システムによって値になったりエンティティになったりするよね
- 増田さんの話
- 分析に便利な粒度…実装上は細かすぎる場合がある
- 値オブジェクトにすべきか、エンティティにすべきか？オブジェクトの特性、費用対効果によって決めれば良いんでは？
- 値オブジェクトの不変性について。実装による理由づけが多い？不変性は不可欠なものなのか？
- 不変性が基本というのも可変性を許容するのも技術上の話では？
- 値を変えたら同じものではない。設計フェーズにおいて値を変える操作を許すと設計が煩雑になる。 不変を基本として設計したほうが簡潔に設計できるという話ではないか
- 開発時…足かせが無いほうがいい。DBではなくapp側で関連性を
- 保守時…DB側で関連を定義する
- 渡辺さん：DBの外部キーを使わない。
- 司会：@MIZO
- レポート・発表：@panther_king
主に、章中で解説されていた関連性と方向性の限定について議論しました
「方向性を限定する」とはどういうことか？
- DOAではデータモデルレベルで関連を設定していく
- DBと連携するアプリケーションでは、関連性を定義する箇所は主に2つあるが、いずれもメリット・デメリットがある
- DBでの定義
- (+)適切な参照制約を定義することで、データ間の整合性が保たれる(外部キー違反による登録・更新の拒否等)
- (-)データ移行の難易度があがる(データ投入時に順番を意識しなくてはならない等)
- アプリケーションでの定義
- (+)インフラ層が変わっても関連性を維持できる(RDBMSでなくなってもよい)
- (-)アプリケーションを経由しないデータ操作により、データの整合性が崩れうる
- DBでの定義
関連性の定義に関する責務はどこが負うべきか？
- 開発時と保守時で重要なファクタが異なるのかもしれない
- 開発時: 実装を前に進めるために、足かせは少ない方がよい(=アプリケーションでの定義)
- 保守時: 予期せぬ不整合を防ぐため、ガードが固い方がよい(=DBでの定義)
「外部キーは使わない」という考え方もある
- 渡辺さんの動的参照では、以下の観点から外部キー制約を推奨していない 0. 外部キーによる制約のみではデータ構造として弱すぎる 0. データ構造に制約を持たせるならレコードレベルでの制約が行われるべき
データの関連性は、ドメインが負うべき責務ではないか
- ≠インフラストラクチャ
- DDDではそもそも、アプリケーションを経由しない操作を前提としていない
- フレームワークで関連性を定義する
from @akipiiさん
経営分析の観点でも関連性が利用できる
マスタに比較してトランザクションの割合が少ない場合は、ビジネスに成長の余地がある
マスタとトランザクションの比率が1:1に近い場合は、ビジネスが成熟している(新たなビジネスを模索するべき)
主に、エンティティの概念について議論しました
現実世界に作用するそのものだけがエンティティではない
- 現実世界をそのままモデル化するとうまくいかない事がある
UNIX系OSのプロセスで考えてみる
- あるプロセスが立ち上がっている間、そのプロセスには一意の番号(ID)が割り振られている
- そのプロセスが終了すると、一意の番号も破棄される
- 破棄された番号は欠番となるのではなく、別のプロセスに割り当てられる
- つまり、プロセス番号そのものではなく、番号が指し示す先にあるものをエンティティとみなす
- ただし、プロセス存在中はIDとプロセスに強い関連がある
DBの顧客テーブルを例にしてエンティティの設計を考えてみる
- 顧客テーブルに属性をどこまで持たせるか？の基準などはあるのだろうか
- 顧客という主体に付属する属性(住所や連絡先など)は、同じテーブル内で定義するべきか
- 正規化のアプローチならば異なるテーブルで定義
- 非正規化のアプローチならば同一テーブルで定義
- テーブルの定義に依らずオブジェクトとしては1つのエンティティであるべき
- オブジェクトとしては平面だが、DB上では立体的になっているケースもある
- 顧客という主体に付属する属性(住所や連絡先など)は、同じテーブル内で定義するべきか
from @UAdachiさん
一意に識別されるIDの付与方法
例)リージョンごとに存在するDB上にデータを保持する
- 書き込みのタイミングなどによって、正しく同期がとれない状況が発生しうる
- IDにリージョン番号を振る
- リージョン番号などの情報を別カラムで保持する
データの整合性を担保できる設計・実装のアプローチが必要
主に、値オブジェクトの具体例について議論しました
IDでの識別に概念上の意味がないものは、値オブジェクトとみなせるのではないだろうか
DBでの多対多関連で考えてみる
- 「ユーザー」とその個人の「趣味」は多対多の関連になる
- 組み合わせそのものに意味があり、(仮にIDが振られていたとしても)IDによる識別は重要ではない
- 実装における値オブジェクトは、DELETE/INSERT操作を伴うものが多い(簡単な実装の場合)
- IDと組み合わせに強い関連がないので、毎回IDが振り直されても問題ない
ディズニーランドのミッキーマウスで考えてみる
- ある都市にあるディズニーランド(以下DL)のミッキーマウスを叩いてみる
- 他の都市のミッキーマウスは痛がらない
- その都市のDLにいるミッキーマウスは値オブジェクト
- 「東京DLのミッキーマウス」「ニューヨークDLのミッキーマウス」はそれぞれ別の概念
- 他の都市のミッキーマウスも痛がる
- その都市のDLにいるミッキーマウスはエンティティ
- どの都市のDLに存在するかは関係なく、「ミッキーマウス」が1つの概念
- 他の都市のミッキーマウスは痛がらない