---
name: spec-domain
description: >
  ユーザー体験側の設計（要件定義・シナリオ・ページ構成など）が完了済みの状態から、
  ドメイン設計以降の技術設計を行うスキル。
  上流の成果物はシナリオ、ページ設計、要件定義書、ユーザーストーリー、フロー図、
  サイトマップなど形式を問わない。何らかの体験設計・要件が存在する前提で、
  ドメイン設計 → ユースケース設計 → DB設計 → テストケース定義 → クロスフェーズ検証を
  一気通貫で実行する。各フェーズでレビュー・修正を行い品質を担保する。
  ユーザーが「ドメイン設計から始めて」「ドメイン以降やって」「技術設計だけ」
  「ドメイン設計して」「ユースケースからDB設計まで」「バックエンド設計して」
  「シナリオはあるからドメインから」「spec-domain」「domain design」
  「ドメインモデリングして」「エンティティ設計して」「テーブル設計して」
  「技術的な設計をやって」「ドメイン〜テストケースまで」
  「要件はあるからドメインから」「フローはできてるから技術設計して」
  などと言ったときにトリガーする。
  spec/ 配下に何らかの上流成果物が既に存在し、ドメイン設計以降を進めたい場合は
  積極的にこのスキルを使うこと。
  部分的なフェーズ（「ドメイン設計だけ」「DB設計だけ」等）の依頼でもこのスキルを使い、
  該当フェーズから開始する。
  途中のフェーズから再開することも可能（既存の成果物を確認して続きから進める）。
---

# Spec Domain

上流の成果物（シナリオ、ページ設計、要件定義、ユーザーストーリー、フロー、サイトマップなど）をもとに、ドメイン設計以降の技術設計を行う。
上流の形式は問わない — 「何を作るか」が明確になっていれば、そこから技術設計に落とし込む。
各フェーズは前フェーズの成果に基づいて進む。レビューで問題が見つかれば即座に修正し、クリーンになってから次へ進む。

## 設計思想

### 実装可能な設計を出す

このスキルのゴールは「設計フェーズを完了すること」ではなく、「実装者が設計書だけを読んで、質問なしにコードを書ける状態を作ること」。エンティティに振る舞いが足りない、ポートのメソッドが未定義、ユースケースの異常系が未検討 — こうした穴が実装時に TODO になる。レビューフェーズはそれを潰すためにある。

### ユーザー体験の設計を前提にする

体験側の設計（要件定義、シナリオ、ユーザーストーリー、ページ構成、フロー等）は完了済みという前提で、技術設計に集中する。上流の成果物が既にあるので、それを忠実に技術で実現することに注力する。

### 決定を記録する

設計中に下した非自明な判断は ADR として記録する。「なぜそうしたか」が残っていれば、実装者が迷わず、将来の変更時にも意図を追える。

## アーキテクチャ制約

設計全体を通じて以下を守る。レビューではこれらへの違反がないかを必ず確認する。

- **ドメインモデルの独立性**: ドメイン層はインフラ層（DB, HTTP, 外部API）に依存しない
- **ビジネスロジックの配置**: ビジネスルールはエンティティまたはドメインサービスに置く。ユースケース層はオーケストレーションのみ
- **集約境界**: 他の集約のエンティティは ID で参照する。直接の参照を持たない
- **ポートによる抽象化**: 外部依存はすべてポート（インターフェース）経由。メソッドシグネチャまで定義する
- **ドメイン間の非循環**: ドメイン間に循環依存を作らない

## ADR（Architecture Decision Records）

設計中に非自明な判断を下したら `spec/adr/NNN-title.md` に記録する。

各 ADR には以下を記載する:
- **ステータス**: 承認済み
- **コンテキスト**: なぜこの決定が必要になったか
- **決定**: 何を決めたか
- **検討した代替案**: 各案と不採用の理由
- **影響**: この決定がもたらす結果・トレードオフ

ADR を書くべき判断の例:
- ドメイン境界の切り方
- 集約の設計（何をひとつの集約にまとめるか）
- 複数のモデリング手法のうちどれを採用したか
- パフォーマンスや一貫性のトレードオフ

## Phase 0: 前提確認

`spec/` 配下を探索し、ドメイン設計の入力となる上流の成果物を特定する。
形式は問わない — シナリオ、ページ設計、要件定義書、ユーザーストーリー、フロー、サイトマップなど、「何を作るか」が分かる成果物があればよい。

- 上流成果物が見つかった場合: 内容を読み込み、設計の入力とする。`spec/index.md` があれば確認し、なければ作成する。
- 上流成果物が見つからない場合: ユーザーに「ドメイン設計の入力となる上流の成果物（要件定義、シナリオ、ページ構成など）が必要です」と案内し、どう進めるか確認する。

既存の `spec/domains/` 等が部分的に存在する場合は、内容を確認して続きから再開する。

確認が完了したら、以降は最後まで自走する（フェーズ間でユーザー承認を挟まない）。

## Workflow Overview

```
Phase 0: 前提確認
  spec/ 配下の上流成果物を探索・特定
  → 既存成果物の確認・再開判定

Phase 1: ドメイン設計
  シナリオ・ページ設計 → spec/domains/index.md → spec/domains/${domain}.md
  → レビュー・修正 → spec/index.md 更新

Phase 2: ユースケース設計
  ドメイン設計 → spec/usecases/${domain}.md
  → レビュー・修正 → spec/index.md 更新

Phase 3: DB設計
  ドメイン設計 → spec/database/index.md
  → レビュー・修正 → spec/index.md 更新

Phase 4: テストケース定義
  ユースケース → spec/testcases/${domain}/${usecase}.md
  → spec/index.md 更新

Phase 5: クロスフェーズ検証
  全成果物を横断的に検証
  → トレーサビリティ・アーキテクチャ適合性・実装可能性
  → spec/index.md 更新

※ ADR は全フェーズを通じて随時作成 → spec/adr/
```

途中のフェーズから再開する場合は、既存の成果物を確認して該当フェーズから開始する。

---

## Phase 1: ドメイン設計

`references/domain-guide.md` を読み、その手順に従ってドメイン設計を行う。

成果物:
- `spec/domains/index.md` — ドメイン一覧
- `spec/domains/${domain}.md` — ドメイン別の詳細設計

完了後、`spec/index.md` を更新する。

---

## Phase 2: ユースケース設計

`references/usecase-guide.md` を読み、その手順に従ってユースケース設計を行う。

成果物:
- `spec/usecases/${domain}.md` — ユースケース定義

完了後、`spec/index.md` を更新する。

---

## Phase 3: DB設計

`references/database-guide.md` を読み、その手順に従ってDB設計を行う。

成果物:
- `spec/database/index.md` — DB設計

完了後、`spec/index.md` を更新する。

---

## Phase 4: テストケース定義

`references/testcase-guide.md` を読み、その手順に従ってテストケースを定義する。

成果物:
- `spec/testcases/${domain}/${usecase}.md` — テストケース（Markdownテーブル）

完了後、`spec/index.md` を更新する。

---

## Phase 5: クロスフェーズ検証

すべてのフェーズが完了した後、成果物を横断的に検証する。
個々のフェーズレビューでは見落としやすいフェーズ間の不整合を検出する。

### トレーサビリティ検証

以下のチェーンをたどり、抜け漏れを特定する:
- **上流の成果物 → ユースケース**: 上流で定義された全操作がユースケースとして実現されているか
- **ユースケース → ドメインモデル**: ユースケースが呼び出すドメインの振る舞いがすべて定義されているか
- **ドメインエンティティ → DBテーブル**: すべてのエンティティ・値オブジェクトの永続化先が定義されているか
- **ポート → ユースケース**: 定義されたポートが少なくとも1つのユースケースから利用されているか

### アーキテクチャ適合性の最終確認

「アーキテクチャ制約」セクションのすべてのルールについて、全成果物を横断的に確認する。

### 実装可能性の最終確認

各ドメインについて「このドメインの実装に必要な情報はすべて揃っているか」を確認する。
不足があれば該当フェーズに戻って補完する。

出力先: `spec/review/cross-phase/${連番}.md`

問題があれば該当フェーズの成果物を修正し、再検証する。クリーンになるまで繰り返す。

完了後、`spec/index.md` を更新する。

---

## レビューの共通原則

各フェーズのレビューでは以下を守る:

- 対象ディレクトリの `review/` 配下に連番ファイル（`001.md`, `002.md`, ...）で記録する
- 無駄な情報を省き、対応が必要な問題点のみ記載する
- ドキュメントの責任範囲をそのレビューの対象に限定する
- 問題がなくなるまでレビュー → 修正を繰り返す

### 各ラウンドの独立性

レビューの各ラウンドは独立した完全なレビューとして実施する。前回のレビューファイルを読まずに、成果物とチェックリストだけを見て一から評価する。こうすることで、前回のラウンドで見落とした問題を次のラウンドで拾える。前回の指摘への対応確認ではなく、毎回ゼロベースの新鮮な目で見直すことが目的。

### レビューの3軸

すべてのフェーズで以下の3軸を確認する（各ガイドに詳細なチェック項目がある）:

1. **実装可能性**: 実装者がこの設計書だけ見てコードを書けるか。型、シグネチャ、制約が揃っているか
2. **アーキテクチャ適合性**: 「アーキテクチャ制約」セクションのルールに違反していないか
3. **トレーサビリティ**: 前フェーズの成果物と整合しているか。漏れているシナリオ・要件がないか

---

## 完了報告

すべてのフェーズが完了したら、作成した設計ドキュメントのサマリーを出す。

```
設計が完了しました！

## 成果物

### ドメイン
- spec/domains/index.md
- spec/domains/${domain}.md (x{数})

### ユースケース
- spec/usecases/${domain}.md (x{数})

### DB設計
- spec/database/index.md

### テストケース
- spec/testcases/${domain}/${usecase}.md (x{数} ファイル)

### ADR
- spec/adr/ (x{数} 件)

### クロスフェーズ検証
- spec/review/cross-phase/
```

---

## 原則

- 各フェーズは前フェーズの成果に基づいて進める — 飛ばさない
- レビューで見つかった問題は即座に修正する — 先送りにしない
- スコープクリープを避け、既存のシナリオ・ページ設計の範囲に集中する
- 実装時に TODO を残さない粒度で設計する。型・シグネチャ・制約・エラーケースまで定義する
- 非自明な判断は ADR に記録する
- `spec/index.md` はフェーズ完了ごとに更新し、成果物と進捗を反映する