---
name: sdd-ddd-internal-design
description: "承認済みの要件・外部設計から、DDD の責務・境界・不変条件、構成と依存、データ、処理、運用、テスト方針、設計判断記録（ADR）を設計するときに使う。"
user-invocable: true
---

# 内部設計

入力: 承認済みの要件と、同じ設計文書の外部設計（窓口から渡されたパスと ID）、既存の構成、編集してよい範囲。

1. 要件文書の対象範囲・機能要件・業務ルール・非機能要件・受入条件・未解決質問、外部設計の部（ない場合は冒頭の省略理由）のうち関係する節と、変更に関係する既存の構成・コードだけを読む。期限が設計の未解決質問は引き継ぐ。無関係な作り直しをしない。
2. 用語・ユースケース・業務ルール・不変条件を特定し、不変条件には根拠の要件 ID を書く。複雑なドメインでは集約・エンティティ・値オブジェクトを選び、単純な処理に不要な層や抽象を増やさない。
3. 新規の開発では5層（プレゼンテーション・コントローラー・アプリケーション・ドメイン・インフラストラクチャ）の責務と依存の向きを示し、ドメインを DB や Web フレームワークに依存させない。既存の構成では、適用する範囲と例外を質問して合意する。
4. 設計は要件文書と同じ名前の `docs/spec/current/design/<機能>.md` の「内部設計」の部に書く。変更の規模に必要な項目だけ（データ、トランザクション、エラー、認証認可、共通機能、運用、テスト方針、技術的な判断）を書き、各受入条件に検証方法を対応付ける。設計 ID は外部設計と共通の `DES-<機能>-001` から未使用の番号を選び、対応する要件 ID を書く。新しい文書や部を作るときだけ [テンプレート](templates/internal-design.md) を読む。既存の文書は差分で直す。
5. 要件や外部設計の変更が必要になったら、内部で辻褄を合わせず、要件定義または外部設計へ戻す提案をする。
6. 後から変えにくい判断は、[ADR のテンプレート](templates/adr.md) で `docs/spec/changes/<ID>/decisions/` に案として残すことを勧める（必須ではない）。既存の暗黙の判断を遡って起票しない。

停止: 必須の技術判断、既存の構成への例外が決まらない。

出力: 変更したファイル、設計 ID と要件 ID の対応、判断の要点、質問。