---
kind: REFERENCE
slug: messaging-inbox-jdbc-postgresql-f06
title: 같은 안전 규칙은 한 공식과 한 강제 시점을 갖는다
topic: contract-domain-and-bounds
project: clean-architecture-backend-template
status: 게시 전
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
rootTreeNode: reference:messaging-inbox-jdbc-postgresql-f06
verifiedOn:            # 이 기록은 이번 회차에 실행 확인을 하지 않았다
source:
  - analysis/messaging/messaging-inbox-jdbc-postgresql.md#L693
---

# 같은 안전 규칙은 한 공식과 한 강제 시점을 갖는다

## 관계

- **bounded purge가 구현돼 있고 호출되지 않아, cleanup이 스스로 막겠다고 한 장애를 일으킨다**
  이 규칙의 근거는 같은 분석 리프의 판정이 소유한다.
- **속성을 이름으로 주장하는 테스트가 그 속성을 보일 수 없는 fake 위에서 통과한다**
  이 규칙의 근거는 같은 분석 리프의 판정이 소유한다.
- **SQL 실패가 재시도 불가로 분류된다**
  이 규칙의 근거는 같은 분석 리프의 판정이 소유한다.

## 목적

같은 종류의 시간 관계가 곱셈과 덧셈으로 다르게 표현되고 강제 시점까지 다르면, 어느 배포가 그 규칙의 보호를 받는지 코드에서 읽을 수 없게 된다.

## 규칙

1. 같은 규칙이 몇 곳에 있는지 센다
   보존 규칙은 세 곳에 있다. InboxRepository javadoc 은 강제하지 않고, 이 leaf 의 InboxRetentionPolicy 는 × 2.0 이며, messaging-claim-check 의 ClaimCheckPolicy 는 brokerRetention + maxRedeliveryWindow 다.

2. 공식이 같은지 본다
   곱셈과 덧셈은 같은 안전 여유를 표현하지 않는다.

3. 언제 강제되는지 본다
   InboxRetentionPolicy.validate() 는 InboxCleanupJob 을 만들 때만 불린다. cleanup 을 배선하지 않은 배포는 보존 검사를 아예 받지 않는다. ClaimCheckPolicy 는 항상 강제한다.

## 적용 조건

보존 기간·재전달 창·타임아웃처럼 시간 관계를 안전 여유로 표현하는 정책이 여러 leaf 에 흩어져 있는 자리.

## 예외

leaf 마다 다른 여유가 필요한 경우는 공식이 아니라 계수가 달라야 한다. 지금은 계수가 아니라 연산 자체가 다르고, 그 차이의 이유가 어느 쪽에도 적혀 있지 않다.

## 예시

세 위치의 공식과 강제 시점. 확인 방법은 그 셋을 나란히 놓고 대조하는 것이다.