---
kind: REFERENCE
slug: messaging-reliability-api-f06
title: 호출 컨텍스트가 계약이면 그 컨텍스트를 검증할 수단을 함께 정한다
topic: declaration-and-document-drift
project: clean-architecture-backend-template
status: 게시 전
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
rootTreeNode: reference:messaging-reliability-api-f06
verifiedOn:            # 이 기록은 이번 회차에 실행 확인을 하지 않았다
source:
  - final/document.md#a19-messaging-reliability-api#L734
---

# 호출 컨텍스트가 계약이면 그 컨텍스트를 검증할 수단을 함께 정한다

## 관계

- **inbox 보존 규칙이 문서로만 있다**
  이 규칙의 근거는 같은 분석 리프의 판정이 소유한다.
- **포트가 bounded/unbounded purge 두 오버로드를 나란히 노출하고, 호출자가 무제한 쪽을 고른다**
  이 규칙의 근거는 같은 분석 리프의 판정이 소유한다.
- **fencing token 경로가 실제 데이터베이스에 대해 실행되지 않는다**
  이 규칙의 근거는 같은 분석 리프의 판정이 소유한다.
- **한 인터페이스가 같은 전이의 두 세대를 갖고, 안전하지 않은 쪽에 `@Deprecated`가 없다**
  이 규칙의 근거는 같은 분석 리프의 판정이 소유한다.

## 목적

위반이 조용하다는 것이 이 계약들의 특징이다. InboxRepository.reserve 를 별도 트랜잭션에서 부르면 "exactly the gap the Inbox exists to close" 가 다시 열리는데, 그 순간 어떤 예외도 나지 않는다.

## 규칙

1. javadoc 이 요구하는 호출 컨텍스트를 목록으로 만든다
   셋이다. OutboxRepository.append 는 호출자 트랜잭션 안, InboxRepository.reserve 는 부작용과 같은 트랜잭션, TransactionalMessageAction 은 자기 트랜잭션을 시작하지 않을 것.

2. 타입으로 표현된 부분과 문장으로만 남은 부분을 가른다
   ReliableMessagePublisher 는 void 반환으로 계약의 일부를 타입에 담았다 — "Handing back a PublishResult here would be a lie". 나머지 셋에는 그런 장치가 없다.

3. 타입으로 못 담으면 검증 수단을 정한다
   구현 leaf 가 트랜잭션 참여를 검증하는 테스트를 두거나, ArchUnit 으로 append 와 reserve 호출부의 트랜잭션 컨텍스트를 검사한다.

## 적용 조건

포트 javadoc 이 호출자 쪽 조건을 요구하는 모든 인터페이스. 트랜잭션 참여·락 보유·스레드 소속이 대표적이다.

## 예외

반환 타입이나 파라미터로 컨텍스트를 강제할 수 있으면 별도 검증이 필요 없다. ReliableMessagePublisher 의 void 가 그 경우다.

## 예시

세 javadoc 의 요구 문장. 확인 방법은 그 셋과 구현의 @Transactional 배치를 대조하는 것이고, 그 대조는 구현 leaf 가 소유한다.