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