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.7 KiB
2.7 KiB
kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, decisionStatus, decidedOn, source
| kind | slug | title | topic | project | status | sourceRevision | rootTreeNode | decisionStatus | decidedOn | source | |||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| PROJECT_DECISION | pool-need-is-a-capability-question | 풀이 필요한지는 "JPA가 켜졌나"가 아니라 "커넥션이 필요한 capability가 있나"로 묻는다 | assembly-ownership | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | decision:pool-need-is-a-capability-question | ADOPTED | 2026-08-30 |
|
풀이 필요한지는 "JPA가 켜졌나"가 아니라 "커넥션이 필요한 capability가 있나"로 묻는다
결정문
관계형 커넥션 풀을 열지 말지는 활성 능력 중 커넥션을 요구하는 것이 하나라도 있는지로 판정한다.
판단 이유
풀은 JPA 의 사유물이 아니다. outbox 와 JDBC 멱등성 저장소와 다중 인스턴스 락과 알림 저장소와 Fileserver 트랜잭션 경로가 전부 커넥션을 필요로 한다.
JPA 가 꺼졌는지만 물으면 두 방향으로 틀린다. 아무도 쓰지 않는 풀을 열거나, 정당하게 쓰고 있던 능력을 조용히 망가뜨린다.
그래서 요구하는 능력을 이름으로 열거하고 그 논리합으로 판정한다. 여섯 조건이다.
퍼시스턴스 JPA 마스터 스위치 outbox 활성 멱등성 제공자가 jdbc 다중 인스턴스 락 활성 알림 플랫폼의 관계형 저장소 요구 Fileserver 플랫폼이 관계형 트랜잭션 제공자와 함께 활성
각 조건은 참일 때 사람이 읽을 수 있는 사유 문자열을 남긴다. 그래서 판정이 예 또는 아니오가 아니라 근거 목록이 되고, 그것이 운영자가 읽을 수 있는 의존성 오류가 된다.
영향
감수하는 것
능력이 추가될 때마다 이 목록을 갱신해야 한다. 빠뜨리면 그 능력은 풀 없이 조립되고 첫 사용에서 실패한다.
목록이 설정 속성 이름에 직접 의존한다. 속성 이름이 바뀌면 이 판정도 함께 바뀌어야 한다.
얻는 것
꺼진 JPA 배포에서 outbox 만 켠 구성이 정상 동작한다.
풀이 열린 이유를 사람이 읽을 수 있다. 판정이 사유 목록을 남기기 때문이다.
근거
- 프레임워크가 기여하는 자동설정까지 세지 않으면 스위치가 아니다 이 결정이 속한 규칙 계열이다.
- 꺼짐은 조건의 반복이 아니라 구조여야 한다 같은 조립 원칙의 다른 면이다.
- 마스터 스위치는 루트 하나가 소유하고 자식 설정은 조건을 갖지 않는다 이 판정을 소비하는 구조다.