Files
llm-wiki/raw/blog-topics/identifier-governance-rule-scoping-by-id-kind-2026-06-01.md

82 lines
5.0 KiB
Markdown

---
title: blog-topic / identifier-governance-rule-scoping-by-id-kind-2026-06-01
source_type: blog-topic
status: raw
related_branches: [feature-resource-identifier-contract, feature-boundary-validation-mapping-contract]
related_projects: [ca-tmpl]
tags: [blog-topic, ca-tmpl, archunit, identifier, architecture, ddd, clean-architecture]
created: 2026-06-01
status_label: ready-for-canonical
target_audience: backend-engineer
inspiration_url:
archive_url:
---
# blog-topic: identifier-governance-rule-scoping-by-id-kind-2026-06-01
> Layer: `raw/blog-topics/` — 채용공고가 아닌 작업·학습·트러블슈팅에서 나온 블로그 글감 원석.
## Parent / 부모
- [[raw/branch-notes/feature-resource-identifier-contract]] — D5(도메인 port + application orchestration) + D17(4 ArchUnit rule) 결정.
- [[raw/errors/archunit-no-uuid-random-trace-id-false-positive-2026-06-01]] — resource-id rule이 trace-id 생성을 잘못 잡은 사건.
## 트리거 / Trigger
- 트리거 유형: `branch-work` / `error`
- 트리거 날짜: 2026-06-01
- 트리거 연결 노트: [[raw/errors/archunit-no-uuid-random-trace-id-false-positive-2026-06-01]]
## 글감 / Topic seed
- 한 문장 요지: 한 시스템에는 ID가 여러 종류(resource / trace / session / idempotency-key / api-key)가 공존하고, 각각 **생성 주체·형식·수명·책임 branch가 다르다**. "모든 `UUID.randomUUID()`를 금지"하는 ArchUnit rule은 합법적인 trace-id 생성을 잡는 false positive를 낳는다 — 거버넌스 규칙은 *ID 종류별로* scope해야 한다.
- 떠오른 계기: resource-id 전용 `no_uuid_random_in_controller``RequestLoggingFilter`의 correlation-id 생성을 잡음.
- 예상 제목 후보:
- "ID 종류별 거버넌스": 한 규칙으로 모든 식별자를 다스리려다 생긴 false positive
- Clean Architecture에서 도메인 식별자를 인프라 결합 없이 생성하기 (port + application orchestration)
- ArchUnit fitness function의 scope 설계: 결정 텍스트 vs reference 코드
## 핵심 주장 후보 / Claim candidates
- DDD factory pattern은 "entity가 자기 ID를 minting"하라고 요구하지 않는다 — factory는 도메인 *service/port*이고, 생성 *호출 시점*은 use case orchestration이다. 도메인 순수성(인프라 라이브러리 미결합)과 server-assigned id를 동시에 만족.
- 식별자 거버넌스 ArchUnit rule은 대상 ID의 *종류*를 명시해야 한다: resource id는 controller/use case에서 직접 생성 금지(factory 강제), trace id는 filter에서 생성 정상(distributed-tracing 책임), idempotency-key는 client 생성(rate-limit 책임).
- rule selector는 spec의 "결정 텍스트(좁은 의도)"와 "reference 코드(넓은 예시)"가 어긋날 때 결정 텍스트를 따른다.
- 사람이 만든 sealed 계층 enumeration이 모듈 경계로 불가능할 때, ArchUnit rule(`no_long_id_pk`)이 compile-time `sealed permits`의 빌드타임 대체가 된다.
## Outline seed
1. ID는 하나의 범주가 아니라 resource/trace/session/idempotency/api key처럼 책임이 나뉜다.
2. 너무 넓은 ArchUnit rule은 합법적인 trace-id 생성까지 잡는 false positive를 만든다.
3. governance rule은 결정 텍스트의 좁은 의도와 ID kind별 owner를 기준으로 scope한다.
## Canonical 전환 후보 / Canonical extraction candidates
- `wiki/projects/ca-tmpl/resource-identifier-format.md` 후보:
- ca-tmpl identifier governance rule scoping 결정과 false-positive boundary.
- `wiki/concepts/resource-identifier-format.md` 후보:
- ID kind별 governance 일반 개념.
## Sources / 근거 후보
- [[raw/branch-notes/feature-resource-identifier-contract]] — resource identifier governance 결정.
- [[raw/errors/archunit-no-uuid-random-trace-id-false-positive-2026-06-01]] — trace-id false-positive 사건.
## 미해결 / Unknown
- 아직 확인해야 할 사실: resource-id rule과 tracing/correlation-id rule의 owner 경계를 concept 문서에 어느 수준까지 일반화할지.
- 과장하면 안 되는 부분: 모든 `UUID.randomUUID()` 호출을 금지하는 것이 정답이라고 쓰지 않는다.
- 블로그로 쓰기 전에 필요한 canonical 정제: 이미 `wiki/projects/ca-tmpl/resource-identifier-format.md`에 연결됨. ID kind별 일반 개념은 blogify 전 확인한다.
## Decision / 처리 결정
- 액션: `promote-to-canonical`
- 이유: `wiki/projects/ca-tmpl/resource-identifier-format.md` 에 identifier kind별 governance scoping 글감으로 반영했다.
- 다음 단계: source canonical이 `verified` 상태이므로 이후 `blogify` 대상으로 삼을 수 있다. 단 모든 `UUID.randomUUID()` 금지가 정답이라고 쓰지 않는다.
## Related / 관련
- 관련 branch: [[raw/branch-notes/feature-resource-identifier-contract]]
- 관련 error: [[raw/errors/archunit-no-uuid-random-trace-id-false-positive-2026-06-01]]
- 관련 interview prep:
- derived blog: 생성 전. 생성 시 `wiki/blog/identifier-governance-rule-scoping-by-id-kind-YYYY-MM-DD.md` 후보