feat!: Member集約を3状態モデルに再設計し、DiscordAccountを独立集約に分離

[KinjiKawaguchi]

Why

室員管理システムのドメインモデル設計書に基づき、ドメイン層を再設計する。
現行のMemberは単一クラスで全状態を扱い、Discord連携やDepartment（CS/BI/IA等）を集約内に持つ構造だが、仕様で求められる室員/未確認/元室員の状態遷移やAffiliationベースの所属管理に対応できていない。

What

Member集約の3状態モデル

• ActiveMember（室員）: MemberId, email, 名前, 個人メール, 学籍番号, 所属
• UnconfirmedMember（未確認）: MemberId, email, 名前, 個人メール
• FormerMember（元室員）: MemberId, email, 名前, 個人メール
• type Member = ActiveMember | UnconfirmedMember | FormerMember

設計上の特徴

• イミュータブル集約: 全操作が新インスタンスを返す
• 型レベルでの状態保証: 元室員に学籍番号でアクセスしようとするとコンパイルエラー
• 二重識別子: MemberId（UUID, Branded Type）は技術的識別子（DB PK, Event集約からの参照用）、emailはビジネス識別子
• Affiliationによる区分表現: 学部生/修士/博士の区分はAffiliationの型が内包
• ドメインイベント収集: 集約の操作でイベントが蓄積され、pullDomainEvents()で取り出し可能

ドメインイベント（12種）

室員登録、除籍、再登録、未確認移行、確認復帰、内部進学、転学部、転学科、転専攻、学籍番号変更、名前変更、個人メールアドレス変更

DiscordAccount集約（独立した境界づけられたコンテキスト）

• 旧MemberからDiscordAccountを分離し、独自の集約ルートとして再設計
• DiscordId（Branded Type）で型安全に識別
• nickNameをDiscord固有の属性として保持
• MemberIdでMember集約を参照

削除・整理

• 旧DiscordAccount（Member集約内のエンティティ）→ 独立集約に移行
• Departments（CS/BI/IA等のenum）→ Affiliation（shared kernel）に置き換え
• Discord関連例外、InvalidDepartmentException を削除

後続PRで対応するもの（Expand → Migrate → Contract）

• Phase 1: スキーマExpand（status列・affiliation列の追加）
• Phase 2: 手動データ移行（各メンバーのstatus/affiliationを設定）
• Phase 3: スキーマContract（department列削除、student_id nullable化）
• アプリケーション層（ユースケース書き換え・新規追加）

Test plan

• ActiveMember: 登録、復元、除籍、未確認移行、名前変更、学籍番号変更
• ActiveMember: 内部進学（学部→修士、修士→博士、不正遷移のエラー）
• ActiveMember: 転学部、転学科（同一学部制約）、転専攻（同一研究科制約）
• UnconfirmedMember: 確認復帰、除籍、名前変更
• FormerMember: 再登録、名前変更
• ライフサイクル全体のイベント蓄積（登録→除籍→再登録、登録→未確認→確認）
• ドメイン層の型エラー: 0件
• 全64テスト合格

🤖 Generated with Claude Code