DongHyeonkaandClaude Opus 5
b2963105a8
The keycloak project ended with four open questions that design could not
settle. A two-VM lab was built to answer them by measurement, and this is
that material: 26 experiments, 125 raw command outputs, 22 browser captures.
Follows the import procedure in README.md.
source/ the originating repository verbatim — 78 documents, 28 SVGs,
8 manifests, plus .source-revision recording the commit
final/ the SSOT
document.md 729 lines written from the 29 experiment documents, not
concatenated: what was predicted, what was measured, and
where the measurement itself was wrong
evidence/raw 125 outputs, flattened to <experiment>__<file> because
the originals collided (01-baseline.txt appeared three
times) and the audit only globs the top level
evidence/meta one per raw file; command and exitCode are null and the
README says why rather than inventing them
evidence/browser 22 captures
assets/ three diagrams through techviz
.techviz/ their VizSpecs
A separate project rather than an addition to keycloak: the B-layer answers
that project's four questions, but the A, C and D layers are about cluster
failure, SSO and operations, and one document.md should hold one subject.
The four question records there can point here through 관계.
Recorded rather than papered over: only three of the 28 diagrams were
remade. The repository forbids hand-drawn SVG and forbids titles inside the
canvas; all 28 originals carry both, so converting them is redrawing, not
reformatting. They stay in source/ and the gap is written into the document.
verify-pipeline.py passes. audit-records.py reports no issues.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2.9 KiB
kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, verifiedOn
| kind | slug | title | topic | project | status | sourceRevision | rootTreeNode | verifiedOn |
|---|---|---|---|---|---|---|---|---|
| REFERENCE | a-validator-is-enforced-by-injection | 검증기는 발행이 아니라 주입이 강제다 | runtime-reachability-and-composition | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | reference:a-validator-is-enforced-by-injection |
검증기는 발행이 아니라 주입이 강제다
목적
검증기를 빈으로 만든 것을 그 검증이 돈다는 증거로 읽어, 아무것도 검사하지 않는 컨텍스트를 검사되는 컨텍스트로 착각하는 것을 막는다.
규칙
-
검증기의 존재와 실행은 다른 사실이다 컨테이너가 발행한 객체는 누군가 그것을 부를 때만 판정을 만든다. 발행 자체는 아무 판정도 아니다.
-
실행 지점을 이름으로 지목할 수 없으면 돌지 않는다고 본다 초기화 콜백이든 조립 코드의 호출이든, 그 지점을 파일과 줄로 댈 수 없으면 검증은 없는 것이다.
-
검증은 컨텍스트가 만들어지는 중에 실패해야 한다 응용 이벤트로 늦추면 실패 시점에 이미 빈이 다 만들어져 있고, 원인이 된 설정 객체가 스택에서 사라진다.
-
검증기가 유일한 소비자인 설정 키를 센다 그 수가 곧 검증이 돌지 않을 때 조용해지는 설정의 수다.
-
검증기가 여럿이면 각각의 실행 지점을 따로 확인한다 같은 파일 안에서 하나만 감싸이는 형태가 실제로 나타난다.
적용 조건
시작 시점에 설정을 판정하는 모든 검증기
자동 설정이 만드는 정책·프로파일·능력 객체
예외
의도적으로 호출자에게 판정을 맡기는 순수 함수형 규칙 객체는 여기 해당하지 않는다. 다만 그 경우 호출자가 어디인지가 자바독에 있어야 한다.
예시
한 가족이 이 결함을 이미 한 번 겪고 고쳤다. 브로커마다 검증기를 발행하면서 아무 데도 주입하지 않아 컨텍스트가 아무것도 검증하지 않았고, 수정은 검증기를 초기화 콜백을 구현한 얇은 타입으로 감싸는 것이었다. 그 타입의 자바독이 이전 상태를 기록으로 남긴다.
같은 형태가 네 곳에 남아 있다. 플랫폼 시작 검증기의 호출자가 0 이고, 같은 자동 설정 안에서 검증기 하나만 감싸이지 않고, 두 아키텍처 규칙이 저장소 소스에 적용되지 않는다.
관계
- 같은 자동 설정 안에서 검증기 하나만 감싸이지 않아 트랜잭션 조건이 검사되지 않는다 이 규칙이 나온 사례다.
- 시작 검증기가 유일한 소비자인 설정 키 넷이 아무것도 게이트하지 않는다 규칙 4 가 나온 사례다.
- 시작 검증기가 시작 시 실행되지 않는다 다른 가족의 같은 형태다.