DongHyeonkaandClaude Opus 5
1f04117bbf
글감 1,001개 중 제1부(§3~§11) 앵커를 하나라도 가진 것은 112개뿐이었다. 나머지 889개는
제2부 모듈 분석 65편의 절 제목에서 나온 것이고, 그것이 재판정이 필요했던 이유다.
주제 44 → 16 (43개가 독자 질문 없이 있었다. 지금은 전부 있다)
글감 1,001 → 123 (제1부 앵커 112 + 제1부가 채택했는데 비어 있던 자리 11)
후보 965 → 1,088 · PENDING 905 → 0
error 3,042 → 0
내려온 889개는 후보 대장에 KEEP_IN_SSOT 로 남는다 — 버린 것이 아니라 분석에 남기고 독립
기록으로 만들지 않기로 한 것이다. 그 글감을 받치던 기록 파일 828개는 지웠다. 계약이 정본이고,
파일이 남아 있다는 이유로 계약에서 뺀 주제가 되살아나면 안 된다. 이력에는 그대로 있다 —
git checkout a0ca2bb -- <경로>.
제1부가 채택했는데 글감이 없던 자리 열하나를 채웠다: mongo high-water mark 가 재전달 이벤트를
삼킨 P1, admin plane 이 가드만 켜고 서비스는 켜지 않은 것과 그 짝인 결정, 실패 어휘 세 층과
SQLState 매트릭스 병합 규칙, 부하 아래에서만 새는 admission 경계, 발행 증거와 완료 판정의
분리, keyset·JSONB 결정 둘.
Concept 17개에 basis-version 을 채우고, 계약 제목과 기록 제목이 갈라져 있던 23건을 기록 쪽에
맞췄다. candidateScope 에 excludedAnchorPattern 을 적어 제2부 앵커만 가진 글감이 다시 올라올
수 없게 한다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
61 lines
2.6 KiB
Markdown
61 lines
2.6 KiB
Markdown
---
|
|
kind: REFERENCE
|
|
slug: conditionalonbean-must-be-satisfiable
|
|
title: @ConditionalOnBean은 조건이 만족될 수 있는지까지 확인해야 한다
|
|
topic: assembly-ownership
|
|
project: clean-architecture-backend-template
|
|
status: 게시 전
|
|
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
|
|
rootTreeNode: reference:conditionalonbean-must-be-satisfiable
|
|
verifiedOn: # 이 기록은 이번 회차에 실행 확인을 하지 않았다
|
|
---
|
|
|
|
# @ConditionalOnBean은 조건이 만족될 수 있는지까지 확인해야 한다
|
|
|
|
## 목적
|
|
|
|
조건부 빈을 선언해 두고 그 조건을 만족시킬 수 있는 경로가 있는지 확인하지 않아, 능력 전체가 조용히 없는 상태를 막는다.
|
|
|
|
## 규칙
|
|
|
|
1. 조건의 뿌리를 끝까지 따라간다
|
|
사슬이면 뿌리 하나가 없을 때 전부 없다. 뿌리 타입의 빈을 만드는 곳이 프로덕션에 있는지 확인한다.
|
|
|
|
2. 테스트의 Bean 은 답이 아니다
|
|
조건을 만족시키는 유일한 곳이 테스트 설정이면 프로덕션에서는 만족되지 않는다.
|
|
|
|
3. 플랫폼이 제공하지 않겠다고 선언한 경우 질문을 바꾼다
|
|
애플리케이션이 제공해야 하는 계약이라면, 물을 것은 조건이 아니라 출하 애플리케이션이 그 계약을 이행하는가다.
|
|
|
|
4. 조건 불만족은 오류로 보고되지 않는다
|
|
Spring 은 조건부 빈이 조건을 만족하지 못하는 것을 정상 동작으로 본다. 로그에도 액추에이터에도 신호가 없다.
|
|
|
|
5. 꺼진 것과 조립될 수 없는 것을 구별할 방법을 남긴다
|
|
둘이 런타임에서 같아 보이면 운영자는 차이를 알 수 없다.
|
|
|
|
## 적용 조건
|
|
|
|
조건부 자동설정을 작성하거나 검토할 때
|
|
|
|
능력이 활성인지 판정할 때
|
|
|
|
조건 사슬이 두 단계 이상일 때
|
|
|
|
## 예외
|
|
|
|
의도적으로 애플리케이션이 채우도록 남긴 확장점은 조건이 프로덕션에서 거짓인 것이 정상이다. 그 경우 그 사실이 문서에 있어야 하고, 이 저장소처럼 출하 애플리케이션이 함께 있다면 그것이 채우는지 확인해야 한다.
|
|
|
|
## 예시
|
|
|
|
outbox 사슬 다섯 단계가 뿌리 두 타입의 빈에 걸려 있고, 그 두 타입을 만드는 프로덕션 코드가 없다.
|
|
|
|
OutboxEnvelopeFactory 를 Bean 으로 만드는 곳은 스타터의 테스트 하나뿐이다.
|
|
|
|
## 관계
|
|
|
|
- **outbox가 둘이고, 출하되는 것은 messaging 플랫폼 쪽이 아니다**
|
|
이 규칙을 적용해 원인이 갈린 사례다.
|
|
- **조건부 빈의 평가 시점 — 파싱 시점과 등록 시점**
|
|
조건이 거짓인 두 번째 이유를 다룬다.
|
|
|