DongHyeonkaandClaude Fable 5.1
b25357c48a
- analysis/·source-index·state.json 을 final/document.md 제2부·제3부로 접었다. SSOT 는 하나다 - 파일럿 — commit-ambiguity-as-a-result 를 새 기준으로 재선별. 후보 14 → 글감 5 (PROMOTE 5 · MERGE_INTO 3 · KEEP_IN_SSOT 4 · 보류 2). 기록 5건을 다시 썼고 그림 1개를 techviz 로 만들었다 - 재선별이 잡은 것: 제1부 §6.2·§11.1 이 자기 §13.2 와 어긋나 있었다(레인을 안 돌렸다 vs 돌렸다) — 정정. 이미 답이 나와 있던 Question 을 HEAD 재실행 질문으로 다시 세웠다. Concept 이 인용한 코드가 SSOT 에 없어 뺐다 - candidateScope·sourceRepository 기록. 나머지 43개 주제는 재선별 대기(PENDING 905) Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
98 lines
5.7 KiB
Markdown
98 lines
5.7 KiB
Markdown
---
|
|
kind: CONCEPT
|
|
slug: three-sources-of-a-capability-answer
|
|
title: 능력 선언의 세 출처와 그것이 파생되지 않을 때
|
|
topic: capability-declaration-vs-proof
|
|
project: clean-architecture-backend-template
|
|
status: 게시 전
|
|
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
|
|
rootTreeNode: concept:three-sources-of-a-capability-answer
|
|
evidenceCapturedOn: 2026-09-01
|
|
assets:
|
|
- key: three-sources-of-a-capability-answer
|
|
file: ../../../final/evidence/rendered/three-sources-of-a-capability-answer.svg
|
|
- key: three-sources-of-a-capability-answer-diagram
|
|
file: ../../../final/assets/diagrams/three-sources-of-a-capability-answer.svg
|
|
evidence:
|
|
- ../../../final/evidence/raw/three-sources-of-a-capability-answer.txt
|
|
source:
|
|
- 원본 분석 절은 final/document.md#a19-messaging-core-api §4.12 · final/document.md#a99 §3.2 이다.
|
|
---
|
|
|
|
# 능력 선언의 세 출처와 그것이 파생되지 않을 때
|
|
|
|
이 플랫폼에서 어댑터가 무엇을 증명할 수 있는지에 답하는 곳이 셋이다. 전송의 능력 상수, 검증기의 같은 이름 메서드, 그리고 운영자가 읽는 지원 매트릭스. 셋이 같은 값을 답해야 한다는 것이 계약인데 그것을 붙드는 장치가 없다.
|
|
|
|
## 관계
|
|
|
|
- **능력 선언은 프로파일에서 파생되어야 하고 상수는 그것을 할 수 없다**
|
|
이 개념에서 나온 규칙이다.
|
|
- **능력 플래그의 무게는 그것을 읽는 코드가 정한다**
|
|
같은 개념의 심각도 판정 쪽이다.
|
|
- **능력 상수가 프로파일 조건보다 오래 살아서 중복 제거 없는 목적지가 가드를 통과한다**
|
|
이 개념이 실제로 발현한 사례다.
|
|
|
|
## 본문
|
|
|
|
<!-- body:start -->
|
|
|
|
이 플랫폼에서 "이 어댑터가 무엇을 증명할 수 있는가" 에 답하는 곳이 셋이다.
|
|
|
|
## 능력을 답하는 세 자리
|
|
|
|
:::evidence key="three-sources-of-a-capability-answer-diagram" alt="능력 질문에서 전송의 상수와 검증기의 메서드와 지원 매트릭스 문서 세 갈래가 나온다" caption="능력을 답하는 세 자리" zoom="false"
|
|
:::
|
|
|
|
전송의 `MessagingCapabilities` 상수(SPI `capabilities(DestinationName)` 가 런타임에 돌려주는 값), 검증기의 같은 이름 메서드(기동 시점 판정용), 그리고 운영자가 읽는 지원 매트릭스 문서다.
|
|
|
|
## MessagingCapabilities 참조 위치
|
|
|
|
:::evidence key="three-sources-of-a-capability-answer" alt="코드베이스에서 MessagingCapabilities 를 검색한 출력 13줄. 이 기록이 세는 참조가 그 출력에 그대로 보인다." caption="MessagingCapabilities 코드베이스 검색 — 13줄 · exit 0" zoom="true"
|
|
:::
|
|
|
|
## 열두 성분과 그 소유자
|
|
|
|
전부 `boolean` 이고 의미는 record javadoc 이 소유한다 — `brokerAcknowledgement` · `replicationOrPersistenceEvidence` · `perMessageSettlement` · `batchSettlement` · `orderedStream` · `keyedOrdering` · `replay` · `delayedDelivery` · `brokerTransaction` · `deduplicatedPublish` · `nativeDeadLetter` · `topologyManagement`.
|
|
|
|
## 세 출처를 붙드는 장치가 없다
|
|
|
|
세 출처가 같은 값을 답해야 한다는 것이 계약인데, 그것을 붙드는 장치가 없다. 그리고 열둘의 무게가 같지 않다 — 부재가 예외를 만드는 것은 `deduplicatedPublish` 하나이고(`DefaultMessagePublisher`), 나머지는 읽히지 않거나 분기에만 쓰인다. record javadoc 이 그 위험을 미리 서술한다 — "a silently weakened guarantee is indistinguishable from a working one until the incident."
|
|
|
|
:::note
|
|
|
|
세 출처를 전수 대조하는 스크립트를 돌리지 않았다. 어댑터별 SSOT 의 §능력 절을 읽어 대조했다
|
|
|
|
:::
|
|
|
|
## 세 출처
|
|
|
|
전송이 SPI 메서드로 돌려주는 값이 런타임의 답이다. 호출자가 목적지를 넘기면 그 목적지에 대한 능력 집합을 받는다.
|
|
|
|
검증기가 같은 이름의 메서드를 갖는다. 이쪽은 기동 시점 판정용이고, 목적지 프로파일이 요구하는 보장을 어댑터가 줄 수 있는지 확인할 때 쓴다.
|
|
|
|
지원 매트릭스 문서가 셋째다. 운영자가 브로커를 고를 때 읽는 표이고, 어댑터별로 열두 성분의 지원 여부를 적는다.
|
|
|
|
## 열두 성분
|
|
|
|
브로커 승인, 복제·지속 증거, 개별 메시지 정착, 배치 정착, 순서 있는 스트림, 키별 순서, 재생, 지연 배달, 브로커 트랜잭션, 중복 제거 발행, 네이티브 데드레터, 토폴로지 관리.
|
|
|
|
전부 불리언이고 의미는 record 의 javadoc 이 소유한다. 성분 이름만으로는 판정할 수 없는 것들이 있다. 순서 있는 스트림은 "순서 단위 안에서 순서가 보존되는가" 이고 그 단위가 무엇인지는 구독 형태가 정한다.
|
|
|
|
## 무게가 같지 않다
|
|
|
|
열둘 중 부재가 예외를 만드는 것은 중복 제거 발행 하나다. 발행자가 중복 제거를 요구하는 목적지에 대해 그 플래그를 확인하고 없으면 던진다.
|
|
|
|
나머지는 읽히지 않거나 분기에만 쓰인다. 순서 있는 스트림은 재시도 결정 엔진이 읽어 순서 보존 재시도를 고를지 정한다.
|
|
|
|
그래서 같은 정도의 과대 선언이라도 결과가 다르다. 심각도를 매기려면 그 플래그를 읽는 코드를 먼저 세어야 한다.
|
|
|
|
## 이 구조가 미리 경고한 것
|
|
|
|
능력 record 의 클래스 javadoc 이 이 상황을 서술한다.
|
|
|
|
> a silently weakened guarantee is indistinguishable from a working one until the incident.
|
|
|
|
조용히 약해진 보장은 사고가 나기 전까지 동작하는 보장과 구별되지 않는다. 세 출처가 갈리는 것이 정확히 그 형태다. 어느 것도 오류를 내지 않고, 셋 중 하나만 읽은 사람은 자기가 읽은 것이 사실이라고 믿는다.
|
|
|
|
<!-- body:end -->
|