# 既存システム知識

## 既存システムの契約

既存システムでは、明示的な API だけでなく、利用者や開発者が観測している値や構造も契約として機能する。コード上は小さな変更でも、運用中の画面、テスト、レビュー、保守手順へ影響が伝わることがある。

既存契約の保持、現行利用側の移行、legacy support は異なる境界に影響する。公開 API、イベント、コマンド、設定、パス、永続化形式の置換では、現行コード、既存テストと利用箇所、保存済みデータ、公開・リリース状態、読込境界への配置や隔離が影響経路を示す。API 互換、event upcaster、data migration・backfill、Read Model rebuild はそれぞれ別の支援境界で機能し、互いを含意しない。

## 因果差分の構造

既存システムの差分は、要求との因果関係によって `required`、`related`、`unnecessary` に分かれる。変更対象ファイルに含まれていることは、その変更の必要性を示さない。

| 分類 | 構造 |
|------|------|
| `required` | 要求を成立させる直接の変化 |
| `related` | `required` の生成元、利用側、検証、整合性を接続する変化 |
| `unnecessary` | 除いても要求が成立し、近接性、好み、一般作法、将来予測だけを根拠とする変化 |

関連変更には必須変更まで辿れる接続関係がある。新しい引数を受ける関数の呼び出し元更新や、永続化境界の置換に伴う旧 store の除去は接続関係を持つ。一方、変更対象に近い公開型名の変更や返却構造の整理は、近い場所にあっても接続関係を持たないことがある。

## 観測可能契約と内部構造

利用者向けの文言や状態、アクセシビリティ、公開 API、イベント、ログ、設定形式、ファイル配置は観測可能な契約になりうる。テストが値を検証している事実は影響経路の証拠になるが、テストが存在するだけでは閉じた内部構造まで公開契約になるとは限らない。

コメントには、算出根拠、プラットフォーム制約、既知の不具合回避、過去の設計判断が保存されていることがある。関数名の言い換えに見えるコメントと、外部からは復元できない理由を記録したコメントでは、変更時の影響が異なる。

## 置換と保存の影響経路

契約の置換では、旧契約を定義する場所、新契約を生成する場所、現行 consumer、検証箇所、保存済みデータ、公開済み利用者が別々の影響点になる。新しい経路の追加だけでは、旧経路の移行や削除が完了したことにはならない。

保存対象の契約では、現在の挙動を示す実装・テスト・利用箇所が基準点になる。内部の実現方法が変わっても、その基準点で観測される値や状態が同じなら、契約を保存できる場合がある。

## 一般品質基準との関係

保守作業では、一般的な設計改善やフレームワーク作法が要求の因果経路と一致するとは限らない。既存構造が理想的でなくても、その構造を変えること自体が新しい利用側移行、レビュー範囲、回帰面を生む。

| 変更 | 主な影響 |
|------|----------|
| 改名 | 検索、履歴追跡、参照箇所、レビュー範囲が変わる |
| ファイル移動 | 所有境界、参照経路、履歴追跡が変わる |
| UI・アクセシビリティ契約変更 | 利用者体験、支援技術、テストへ影響する |
| テスト期待値の緩和 | 既存の回帰検出力が低下する |
| 追加抽象化 | 将来の柔軟性と引き換えに現在の理解経路と変更点が増える |