Files
document-haness/docs/clean-architecture-backend-template/tech-log-studio/multitenancy-isolation/question/openquestion-analysis-finding-a02-f003.md
T
DongHyeonkaandClaude Opus 5 b2963105a8 docs(keycloak-session-store): import the session-storage lab as a new project
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>
2026-09-04 22:51:59 +09:00

2.3 KiB

kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, questionStatus, verifiedOn
kind slug title topic project status sourceRevision rootTreeNode questionStatus verifiedOn
QUESTION analysis-finding-a02-f003 bounded operational record identifiers multitenancy-isolation clean-architecture-backend-template 게시 전 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 open-question:analysis-finding-a02-f003 OPEN

bounded operational record identifiers

운영 레코드의 네임스페이스와 키가 경계가 있다고 문서에 적혀 있는데, 생성자는 공백 여부만 확인한다. 그 경계를 공유 계약이 소유할지 어댑터가 소유할지 정해지지 않았다.

사실

운영 레코드 문서가 네임스페이스와 키를 경계가 있는 값으로 설명한다.

생성자는 공백 여부만 확인한다.

가정

각 어댑터가 자기 제공자의 제한을 알아서 지킬 것이라고 전제하고 있다. 그 전제를 확인하지 않았다.

미지수

제공자별 키 크기와 문자 집합 제한을 공유 계약이 소유해야 하는가 어댑터가 소유해야 하는가.

여러 제공자가 공통으로 요구하는 최소 경계가 있는가.

제약

공유 계약이 특정 제공자의 제한을 담으면 그 계약이 제공자에 묶인다.

어댑터가 각자 검증하면 같은 검사가 여러 곳에 생긴다.

선택지

공유 값 객체에서 공통 최소 경계를 강제한다 여러 제공자가 공통 최소 경계를 요구하면 이쪽이 맞다.

공유 문서를 좁히고 어댑터 경계에서 검증한다 제한이 제공자별이면 공유 계약은 경계를 주장하지 않는 편이 정확하다.

다음 검증

실제 제공자와 어댑터의 식별자 제한을 조사하고 프로덕션 생성 지점과 대조한다. 경계값 픽스처를 추가한다.

여러 제공자가 공통 최소 경계를 요구하면 공유 값 객체에서 강제한다.

제공자별이면 공유 문서의 표현을 좁히고 어댑터 경계에서 검증한다.

관계

  • 카디널리티 경계를 타입으로 표현하기 경계를 타입으로 표현하는 같은 계열의 개념이다.
  • 위험한 조합은 정책이 아니라 생성자가 거부하게 만든다 값 타입에서 강제하는 방향의 규칙이다.