principle-boundary-discipline

境界の厳守

検証、型の絞り込み、エラー処理はシステム境界に配置します。内部コードは無条件に信頼します。ビジネスロジックは純粋関数に置きます。シェルは薄く、機械的なものにします。

理由： 検証があちこちに散らばると、冗長で煩雑になり、誤った安心感を与えます。フレームワークの配線からロジックを切り離せば、フレームワークなしでテストできます。

パターン：

• 境界では（CLI 引数、設定ファイル、外部 API、ネットワークプロトコル）：検証し、エラーを返し、防御的に処理します。
• システム内部では： 型付きデータを使い、エラーを伝播させ、再検証はしません。型を信頼します。
• 境界をまたぐ場合： 境界の内部表現ではなく、ドメインの概念を公開します。汎用的な仕組みは内部に、特殊用途のポリシーは境界に置きます。

適用例：

検証とエラー処理：

• ビジネスロジックの内部ではなく、解析時（境界）に設定を検証します
• 境界で生データをドメイン型に解析します
• 公開インターフェースを通じて、トランスポート、ストレージ、フレームワーク、ワイヤーの型を再エクスポートしません
• 境界ですでに検証済みであれば、呼び出しチェーンの深い箇所で冗長な nil チェックを行いません

コード構成：

• フレームワークへの依存がない純粋関数にビジネスロジックを置きます
• レビューでは、外側を参照するインポートを指摘します。ドメインまたはポリシーモジュールが、フレームワーク、ドライバー、ORM、IO ライブラリ、生成されたスキーマ型、アダプターモジュールをインポートしている場合、型専用インポートも含め、それらは呼び出し元からプレーンなデータとして受け取るべきです
• 解析関数：生バイト列から型付き状態への純粋な変換
• プロンプトの構築：構造化された状態を受け取り、文字列を返します
• スコアリングと評価：状態から結果への純粋な変換

テスト：

• 「このデータは今、システム境界を越えていますか？」そうでなければ、検証は冗長です。
• 「シェルから呼び出すだけの純粋関数にできますか？」できる場合は、切り出します。