SOP: レイヤードドメインアーキテクチャ

この SOP は、エージェントが境界を繰り返し違反している、レイヤー間で ロジックを複製している、または数セッション後にレビューが困難なコードを 生成している場合に使用します。

目標

ドメインの境界を、エージェントが構造を知らずに劣化させることなく 迅速に移動できるほど明示的にする。

ターゲットモデル

ビジネスドメイン内では、次の方向フローを推奨する:

Types -> Config -> Repo -> Service -> Runtime -> UI

横断的関心事は、明示的なプロバイダーまたはアダプターを通じて出入りするべきである。 共有ユーティリティはドメインの外に置き、ドメインロジックを蓄積しないようにする。

セットアップチェックリスト

• ARCHITECTURE.md で現在のドメインを定義する。
• ARCHITECTURE.md に許可される依存関係の方向を記述する。
• 認証、テレメトリ、外部 API などの横断的インターフェースを記録する。
• 現在最も困難な境界違反について短いメモを1つ追加する。
• lint、テスト、またはスクリプトによって機械的に強制すべきものを決定する。

実行 SOP

1. 実装スタイルに触れる前に、コードベースをドメインにマッピングする。
2. 各ドメインについて、許可されるレイヤーの順序を特定する。
3. すべての横断的関心事を特定し、プロバイダーまたはアダプターを通じてルーティングする。
4. 曖昧な共有ロジックを、所有するドメインまたは真に汎用的なユーティリティに移動する。
5. ルールを ARCHITECTURE.md に文書化する。
6. 最もコストの高い違反に対して1つの実行可能ガードレールを追加する。
7. 変更後に品質スコアを更新する。

完了の定義

• 新しいエージェントがどのレイヤーが変更を担当しているかを判断できる。
• UI コードがリポジトリや外部副作用に直接アクセスしなくなる。
• 横断的関心事に名前付きのエントリポイントがある。
• 少なくとも1つの重要な境界が機械的に強制されている。

更新すべきリポジトリ成果物

• ARCHITECTURE.md
• docs/QUALITY_SCORE.md
• 根拠が変更された場合の docs/design-docs/
• docs/PLANS.md またはアクティブな実行計画