Souther の behavior が Allowed または Refused を返すと宣言した場合、この二つは業務判断が完了したときの帰結を表す。 注入された Java 実装でデータベース接続の切断や通信のタイムアウトが起きると、behavior はどちらも返さず、Java の例外によって評価自体が完了しない。 したがって、アプリケーション全体の操作は概念上、業務上の帰結に加えて実行失敗も持つが、Souther は前者だけをドメインモデルの型に含める。
これは実行失敗を無視する設計ではなく、扱う責務を分ける設計である。 フォロー関係を取得できなかったことを NotFollower に変換すると、事実を確認できなかっただけなのに、フォローしていないという業務上の判断を捏造してしまう。 一方、接続の再試行、処理期限、回路遮断、ログ記録、HTTP の応答コードは実行環境によって変わり、閲覧可否の規則ではないため、Java 側のアプリケーション境界で扱う。
この境界は、技術的失敗への対処が業務に影響しないことを意味しない。 たとえば決済サービスへ接続できないとき、注文を保留状態にして後で再実行することが業務上の約束なら、保留は Souther の戻り値に含めるべきドメインの帰結である。 その場合でも SQLException やタイムアウトをそのままモデルへ持ち込むのではなく、Java 側が技術的な失敗を業務上の意味へ翻訳する。
Souther が保証する完全性は、正常に評価を完了できたドメイン判断についての完全性であり、システム全体の実行が必ず成功するという完全性ではない。 実行失敗を検査必須の型にする必要があるなら、Java 側の入口で Souther の呼び出しを ExecutionFailure と業務上の帰結を区別する型に包める。 ただし、その ExecutionFailure は behavior の業務契約ではなく、アプリケーションの実行契約に属する。
この分離により、ドメイン分析で見つけた制約と状態遷移を、データベース製品や再試行方式の都合で広げずに保てる。
https://zenn.dev/kawasima/articles/souther-ddd-trilemma