feat: PC相談室カルテ集約のドメインモデルを追加

[KinjiKawaguchi]

概要

PC相談室のカルテ（相談記録）を表すKarte集約を追加する。

背景

PC相談室では相談対応の記録をカルテとして管理している。このPRではカルテのドメインモデルを定義し、ドメイン層に集約として追加する。

集約の構造

Karte（集約ルート / immutable）
├── Client          相談者（Student | Teacher | Staff | Other）
├── Consent         同意事項
├── Consultation    相談事
│   ├── categories      相談カテゴリ（複数選択）
│   ├── targetDevice    対象機器
│   └── troubleDetails  トラブル詳細
└── SupportRecord   対応記録
    ├── assignedMemberIds  担当メンバー
    ├── content            対応内容
    ├── resolution         解決ステータス（resolved | unresolved → FollowUp）
    └── workDuration       作業時間

設計の要点

1. immutableな「記録型」集約

カルテは一度書いたら変わらない「記録」としてimmutableに設計した。

• create() で新規作成、correct() で訂正（記録ミスの修正用）
• correct() は recordedAt を保持し lastUpdatedAt のみ更新する
• reconstruct() は永続化データからの復元用（バリデーションなし）

2. Recorded<T> — 過去データの欠損を型で表現

過去のカルテには一部フィールドが存在しない。null/undefinedに暗黙の意味を持たせず、{ type: "recorded", value: T } | { type: "notRecorded" } の判別共用体で明示する。

• create() では全フィールドを生の値で受け取り、内部で recorded() に包む → 新規カルテは常に完全
• reconstruct() では Recorded<T> をそのまま受け取る → 過去データの欠損を許容

3. Branded型 + ファクトリ関数によるVO実装

WorkDuration, KarteId などの値オブジェクトは、既存の ValueObject<T> 基底クラスを使わずbranded型 + ファクトリ関数で実装した。

理由: ValueObject<T> 基底クラスは equals() が JSON.stringify 比較に依存しており実装として脆い。今後他の集約でも基底クラスから剥がしていく可能性があるため、新規コードでは採用しなかった。

4. KarteRepositoryは find/save のみ

ユースケースが明確なメソッドだけ定義し、CRUD網羅はしない（YAGNI）。検索や一覧のユースケースが出た時点で追加する。

5. Recorded<T> の値にはドメインルールを適用

Recorded<T> が recorded であれば、その値はドメインルールに従うべき。

• assignedMemberIds: Recorded<NonEmptyArray<string>> — 記録されているなら1人以上
• categories: Recorded<NonEmptyArray<ConsultationCategory>> — 記録されているなら1つ以上

議論したいこと

• カルテは本当に変更すべきでないか？ 現在の設計は「記録型（immutable）」を前提としている。correct()は記録ミスの訂正用として用意したが、そもそもカルテは一度記録したら変更不可とすべきか、それとも訂正を許容すべきか。
• 変更履歴を残すべきか？ 現在のcorrect()は最新の状態だけを保持し、変更前の内容は残らない。訂正を許容する場合、誰がいつ何を変更したかの履歴（監査ログ）が必要ではないか。
• FollowUp「その他」選択時の自由記述フィールド が必要か（ドメインエキスパートとの議論待ち）

テスト

• WorkDuration: バリデーション境界値（0分OK、負数/小数/NaN → 例外）
• Karte: create/correctのドメインロジック（タイムスタンプ、Recorded包装、訂正時のid/recordedAt保持）

🤖 Generated with Claude Code

[KinjiKawaguchi]

相談カテゴリは何処に書かれている?

[KikyoNanakusa]

カルテは基本的にimmutableで良いです
カルテの内容の変更は基本的にspreadsheet経由なので細かい監査ログは残しようがありません。
Follow-upのその他は過去20年使用実績がほとんどないのでそもそも必要か分かりません。とりあえず過去の記録と整合性を取るために存在させておけば良いです

[devin-ai-integration]

Devin Review found 3 new potential issues.

[devin-ai-integration]

Devin Review found 1 new potential issue.