principle-boundary-discipline

境界での責務分離

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

理由： 検証が散在すると煩雑で冗長になり、安全性について誤った安心感を与えます。フレームワークの配線処理にロジックを持ち込まないことで、フレームワークなしでテストできます。

パターン：

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

適用例：

検証とエラーハンドリング：

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

コードの構成：

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

テスト時の確認事項：

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