なぜ必要なのか

決済会社を変えるだけなのに、注文ルールと全画面を書き直すことがあります。機能が互いの保存先を直接変更し、責任の持ち主が曖昧だと変更が広がります。有名なパターンや箱の図を選ぶ前に、変更をどこが受け持ち、他の部分は何を信頼できるかを決める必要があります。

どう解決するのか

  1. 注文確定など実際の操作を一つたどります。注文の確認、在庫予約、決済要求、結果通知を普通の言葉で並べます。在庫予約後に決済が失敗する場合も含めます。成功だけの図では見えない調整や復旧の仕事が現れます。存在しない将来機能まで先に設計する必要はありません。
  2. 所有者を割り当てます。Orderは確定ルール、Inventoryは在庫、決済連携部は外部との通信を持ちます。チェックアウトの調整役は順番と復旧を担当します。二つのモジュールが同じ注文の確定を別々に判断しないようにします。最終的な責任の所在を明らかにします。
  3. 境界を越える情報を記述します。識別子、操作、結果、失敗の種類を確認します。呼び出す側が内部テーブルやフレームワークのオブジェクトまで知る必要のない、小さな契約にします。データを直接変更できる所有者と、その所有者へ変更を頼む側も区別します。
  4. 本当に変わりそうな部分を探します。決済会社の交換があり得るなら変換とエラー処理を隔離します。いつも一緒に変わり所有者も同じなら、間に契約を増やすだけでは管理作業が増えるかもしれません。小さなアプリに大組織の構造をそのまま持ち込まず、分離の理由を示します。
  5. 一つの代替物で境界を確かめます。仮の決済結果だけで注文ルールを試せますか。応答が遅れても状態が明確で、再試行や復旧の担当者がいますか。フォルダーを数えるより、こうした検証の方が結合の実態を示します。復旧できない状態を観測する役割も必要です。

AIに短い責任表と依存方向の図を書かせ、その後でクラスやメソッドを具体化します。利用者は全体の役割、動作、運用条件を確認すればよく、すべてのオブジェクト名を承認する必要はありません。所有権が変われば図も更新します。古い図だけで今のコードが境界を守っているとは証明できません。

他の担当者にも契約だけで同じ失敗をたどってもらい、所有者が二人に見える段階は責任表で明確にします。

UI↓   Use case↓   DomainPort ← Adapter

どんな考え方なのか

システムの責任、所有権、契約、依存関係を決めるのがソフトウェアアーキテクチャです。関心の分離とカプセル化は契約の内側で実装を交換できるよう助けます。レイヤー、ポート、サービスは表現の選択肢です。その管理費用を正当化するのは実際の変更や共同作業の必要性であり、図の箱の数ではありません。