Files
document-haness/docs/clean-architecture-backend-template/tech-log-studio/assembly-ownership/reference/reference-conditionalonbean-must-be-satisfiable.md
T

63 lines
3.3 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은 조건이 만족될 수 있는지까지 확인해야 한다
조건부 빈을 선언해 두고 그 조건을 만족시킬 수 있는 경로가 있는지 확인하지 않아 능력 전체가 조립되지 않는 상태를 막는다. 조건 불만족이 application failure나 health failure로 자동 승격되지 않을 수는 있지만, condition evaluation evidence 자체가 사라지는 것은 아니다. Spring Boot의 `ConditionEvaluationReport`와, endpoint가 노출된 경우 Actuator `/actuator/conditions`에서 match 여부와 이유를 확인할 수 있다.
## 목적
조건부 빈을 선언해 두고 그 조건을 만족시킬 수 있는 경로가 있는지 확인하지 않아, 능력 전체가 조용히 없는 상태를 막는다.
## 규칙
1. 조건의 뿌리를 끝까지 따라간다
사슬이면 뿌리 하나가 없을 때 전부 없다. 뿌리 타입의 빈을 만드는 곳이 프로덕션에 있는지 확인한다.
2. 테스트의 Bean 은 답이 아니다
조건을 만족시키는 유일한 곳이 테스트 설정이면 프로덕션에서는 만족되지 않는다.
3. 플랫폼이 제공하지 않겠다고 선언한 경우 질문을 바꾼다
애플리케이션이 제공해야 하는 계약이라면, 물을 것은 조건이 아니라 출하 애플리케이션이 그 계약을 이행하는가다.
4. 조건 불만족과 관측 가능성을 구분한다
조건이 맞지 않았다는 사실이 application failure나 health failure로 자동 승격되지 않을 수 있다. 그렇다고 condition evaluation evidence가 없어지는 것은 아니다. `ConditionEvaluationReport`와, endpoint가 노출된 경우 `/actuator/conditions`에서 positive/negative match와 이유를 확인한다.
5. 꺼진 것과 조립될 수 없는 것을 구별할 방법을 남긴다
둘이 런타임에서 같아 보이면 운영자는 차이를 알 수 없다.
## 적용 조건
조건부 자동설정을 작성하거나 검토할 때
능력이 활성인지 판정할 때
조건 사슬이 두 단계 이상일 때
## 예외
의도적으로 애플리케이션이 채우도록 남긴 확장점은 조건이 프로덕션에서 거짓인 것이 정상이다. 그 경우 그 사실이 문서에 있어야 하고, 이 저장소처럼 출하 애플리케이션이 함께 있다면 그것이 채우는지 확인해야 한다.
## 예시
outbox 사슬 다섯 단계가 뿌리 두 타입의 빈에 걸려 있고, 그 두 타입을 만드는 프로덕션 코드가 없다.
OutboxEnvelopeFactory 를 Bean 으로 만드는 곳은 스타터의 테스트 하나뿐이다.
## 관계
- **outbox가 둘이고, 출하되는 것은 messaging 플랫폼 쪽이 아니다**
이 규칙을 적용해 원인이 갈린 사례다.
- **조건부 빈의 평가 시점 — 파싱 시점과 등록 시점**
조건이 거짓인 두 번째 이유를 다룬다.