principle-boundary-discipline

境界の規律

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

理由： 検証が散在すると、冗長でノイズが多く、安全であるという誤った安心感を生みます。データの検証は境界で一度だけ行います。フレームワークの配線からロジックを切り離し、フレームワークなしでテストできるようにします。

パターン：

• 境界（CLI 引数、設定ファイル、外部 API、ネットワークプロトコル）では： 検証し、エラーを返し、防御的に処理します。
• システム内部では： 型付けされたデータ、エラーの伝播、再検証なし。型を信頼します。

適用例：

検証とエラー処理：

• ビジネスロジックの内部ではなく、解析時（境界）に設定を検証します
• 境界では生データを保存し、使用箇所で遅延解析します
• 境界ですでに検証されている場合は、呼び出しチェーンの奥深くで冗長な nil チェックを行いません

コード構成：

• フレームワークに依存しない純粋関数にビジネスロジックを置きます
• 解析関数：生のバイト列を型付けされた状態に変換する純粋な変換処理
• プロンプトの構築：構造化された状態を入力し、文字列を出力します
• スコアリングと評価：状態を結果に変換する純粋な変換処理

テスト：

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