-
- いいね！0
ガミネ
@gaminessium
一件の注文をまとめて請求するモデルの場合、注文を請求に依存させると、業務上の時系列（先払いをするケース）に沿わない場合がある これも中間エンティティによって時系列が破綻しないよう設計する #現場から学ぶモデル駆動設計
2021-11-24 20:00:42
Kentaro Takasaki | アクティアCOO
@ken_takasaki
業務的な時系列的な並びを変えてはならない。 例えば、「注文」に「請求ID」を保持して、「請求」が決まった時にデータを設定しにいく。後から情報を変えてしまうことになる。 これ、データモデリングしてもらっていると意外とやっちゃう人が多いんだよな。 #現場から学ぶモデル駆動設計
2021-11-24 20:00:43
オミ・グッドラッカー 🐟12.07 01.14 01.20 02.04 03.30
@omiend
請求に注文IDを持たせないのが、非依存だからってやつかな（さっきの動物園の話）。 中間テーブル（テーブルではないけど）をもたせて紐付ける方法なるほどー #現場から学ぶモデル駆動設計
2021-11-24 20:00:58
どて
@dotegasuki
イベントは事実として記録する。後からアップデートするのは業務の流れを表したモデルになっていない？関連テーブルで紐づける。例えば、注文と請求であれば注文は注文として記録しておき請求は請求で記録する。請求発生時に対象の注文と請求の関連を作成する #現場から学ぶモデル駆動設計
2021-11-24 20:04:41
山口征啓@九大MHA, LIFE Study
@ID_HelpDesk
ここから細かい話 サブタイプ リソースのサブタイプは区分によって分類すると良い ex 社員というスーパータイプに現役社員と退職社員 退職社員は氏名をもたない #現場から学ぶモデル駆動設計
2021-11-24 20:05:59
山口征啓@九大MHA, LIFE Study
@ID_HelpDesk
イベント自体が親子構造を持つケース 注文と注文明細 注文明細は日時属性をもたないが、ひっくるめてイベントと考える たとえば明細毎に出荷する場所が異なったりするので、出荷は注文明細を使う #現場から学ぶモデル駆動設計
2021-11-24 20:06:00
Griezin
@griezin
後続のリレーションとかどこまでを含めて一つのドメインイベントというかははっきりしてないんだよなあ #現場から学ぶモデル駆動設計
2021-11-24 20:06:05
穿短裤@川崎
@Duanku_Jingdu
イベントーイベント間の関連 * 業務的な時系列的な並びを変えてはいけない 注文ー請求（n対1）だとしても、中間に関連エンティティを挟む。もし注文エンティティに請求IDを持ってしまうと、初期値NULL入れておいて請求時に後追いでUPDATEという二度手間が発生 #現場から学ぶモデル駆動設計
2021-11-24 20:06:16
穿短裤@川崎
@Duanku_Jingdu
リソースーリソース間の関連 * リソースにはライフサイクルがある * 依存/非依存を考える 競走馬or動物園の馬の例 #現場から学ぶモデル駆動設計
2021-11-24 20:07:43
ガミネ
@gaminessium
注文に対応する概念として出荷があるが、実際には注文明細を介して、時系列の破綻なく関連を表現できる #現場から学ぶモデル駆動設計
2021-11-24 20:07:49
増田 亨
@masuda220
入会アクティビティのサブタイピング。 申込・審査・会員証発行・免許登録。 それぞれがイベントなので、サブタイプ間の依存関係も持たせる。 B＋ツリーみたいな絵柄になるんだな。なるほど。 #現場から学ぶモデル駆動設計
2021-11-24 20:12:34
オミ・グッドラッカー 🐟12.07 01.14 01.20 02.04 03.30
@omiend
イベントを残すこと自体が業務設計、つまり「どのイベントが必要か」を見つけ出すところから必要なんだな。 #現場から学ぶモデル駆動設計
2021-11-24 20:13:35
DJらびたろ
@rabitarochan
社員が部署に「配属」されることを見つけるのが「業務設計」で、それを永続化するかしないかが「システム設計」ってイメージかな。 #現場から学ぶモデル駆動設計
2021-11-24 20:14:36