前節ではシンプルな依存関係のRepositoryを見てきましたが、もっと複雑な依存関係を持っていることも多々あります。

flowchart LR

見積 --> 発注 --> 納品 --> 受領 --> 請求 --> 支払

上記は処理順を表現しています。

依存関係は処理順の逆になります。

flowchart RL

支払 --> 請求 --> 受領 --> 納品 --> 発注 --> 見積

見てもらえるとわかる通り、未来が過去に依存するようになっています。

このルールを守ってモデリングをしていきます。

classDiagram
direction　LR

class quote{
	UUID quote_id PK
	timestamp created_at
}

class order{
	UUID order_id PK
	UUID quote_id FK
	timestamp created_at
}
quote <|-- order

class supply{
	UUID supply_id PK
	UUID order_id FK
	timestamp created_at
}
order <|-- supply

class accept{
	UUID accept_id PK
	UUID supply_id FK
	timestamp created_at
}
supply <|-- accept

class billing{
	UUID billing_id PK
	UUID accept_id FK
	timestamp created_at
}
accept <|-- billing

class payment{
	UUID payment_id PK
	UUID billing_id FK
	timestamp created_at
}
billing <|-- payment

これにvalueテーブルを追加するとデータモデリングは終了です。

後はそれぞれのRepositoryを作ればokです。

<aside> 💡 今回は例として直前のidに依存する形でデータモデリングしましたが、恐らくorder_idを使いまわすのが適切でしょう。 ドメインモデルに出てこないidはヘルパーidとして定義しておきます。

</aside>

このように、idに焦点を当てると簡単にデータモデリングをすることができます。

idの単位でデータモデリングができるとRepositoryを作る単位もわかるので、ドメインモデリングに悩んだら一度データモデリングをしてみるのも手かもしれません。