社員Repositoryにのみ焦点を当てて実装方法を見てきましたが、次は依存関係のある複数のRepositoryについて見ていきます。

まずは下記を見てください。

classDiagram
direction　TB

class employee{
	UUID employee_id PK
	timestamp created_at
}

class department{
	UUID department_id PK
	timestamp created_at
}

class assignment{
	UUID employee_id FK
	UUID department_id FK
	timestamp created_at
}
employee <|-- assignment
department<|-- assignment

社員、部署、配属をモデリングしたものです。

ここで「配属理由」というvalueテーブルを追加したいとします。

するとこのようになりました。

classDiagram
direction　TB

class employee{
	UUID employee_id PK
	timestamp created_at
}

class department{
	UUID department_id PK
	timestamp created_at
}

class assignment{
	UUID employee_id FK
	UUID department_id FK
	timestamp created_at
}
employee <|-- assignment
department<|-- assignment

class assignment_reason{
	UUID employee_id FK
	UUID department_id FK
	text reason
	timestamp created_at
}
employee<|-- assignment_reason
department<|-- assignment_reason

配属理由valueテーブルがemployee_idとcompany_idのふたつのidに依存するようになってしまいました。

「valueテーブルはひとつのidテーブルにしか依存しない」というルールを破ってしまいました。

では、配属理由テーブルが配属テーブルに依存するように修正してみましょう。

classDiagram
direction　TB

class employee{
	UUID employee_id PK
	timestamp created_at
}

class department{
	UUID department_id PK
	timestamp created_at
}

class assignment{
	UUID assignment_id PK
	UUID employee_id FK
	UUID department_id FK
	timestamp created_at
}
employee <|-- assignment
department<|-- assignment

class assignment_reason{
	UUID assignment_id FK
	text reason
	timestamp created_at
}
assignment<|-- assignment_reason

配属テーブルに配属idを追加し、配属理由テーブルが配属idに依存するようにしました。

これをすることで「idテーブルでは依存関係を表現する」「valueテーブルでは値を表現する」という整理をすることができました。

idテーブルとvalueテーブルのルールを守ると、このようにデータの責務が明確になり、凝縮度が高まります。

データモデリングはこれで一旦終わりにし、Repositoryを作っていきます。

ライフサイクルごとにRepositoryを作る

ライフサイクルとは、それが生まれてから死ぬまでの期間のことです。

プログラミングの業界では特にインスタンスの生成から破棄までの期間のことを言います。

イミュータブルデータモデルではデータの破棄はしないため、データの生成に焦点を当てます。