docs(clean-architecture-backend-template): 제1부가 채택한 것만 글감으로 남기고 다시 고른다
글감 1,001개 중 제1부(§3~§11) 앵커를 하나라도 가진 것은 112개뿐이었다. 나머지 889개는
제2부 모듈 분석 65편의 절 제목에서 나온 것이고, 그것이 재판정이 필요했던 이유다.
주제 44 → 16 (43개가 독자 질문 없이 있었다. 지금은 전부 있다)
글감 1,001 → 123 (제1부 앵커 112 + 제1부가 채택했는데 비어 있던 자리 11)
후보 965 → 1,088 · PENDING 905 → 0
error 3,042 → 0
내려온 889개는 후보 대장에 KEEP_IN_SSOT 로 남는다 — 버린 것이 아니라 분석에 남기고 독립
기록으로 만들지 않기로 한 것이다. 그 글감을 받치던 기록 파일 828개는 지웠다. 계약이 정본이고,
파일이 남아 있다는 이유로 계약에서 뺀 주제가 되살아나면 안 된다. 이력에는 그대로 있다 —
git checkout a0ca2bb -- <경로>.
제1부가 채택했는데 글감이 없던 자리 열하나를 채웠다: mongo high-water mark 가 재전달 이벤트를
삼킨 P1, admin plane 이 가드만 켜고 서비스는 켜지 않은 것과 그 짝인 결정, 실패 어휘 세 층과
SQLState 매트릭스 병합 규칙, 부하 아래에서만 새는 admission 경계, 발행 증거와 완료 판정의
분리, keyset·JSONB 결정 둘.
Concept 17개에 basis-version 을 채우고, 계약 제목과 기록 제목이 갈라져 있던 23건을 기록 쪽에
맞췄다. candidateScope 에 excludedAnchorPattern 을 적어 제2부 앵커만 가진 글감이 다시 올라올
수 없게 한다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
DongHyeonka
co-authored by
Claude Opus 5
Claude Opus 5
parent
a0ca2bb72a
commit
1f04117bbf
-96
@@ -1,96 +0,0 @@
|
||||
---
|
||||
kind: CASE
|
||||
slug: the-same-repository-bound-a-decision-once-and-not-the-other-time
|
||||
title: 같은 저장소가 "결정을 그 결정이 판정한 대상에 묶는 것"을 한 번은 맞게, 한 번은 틀리게 썼다
|
||||
topic: duplicate-mechanisms
|
||||
project: clean-architecture-backend-template
|
||||
status: 게시 전
|
||||
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
|
||||
rootTreeNode: case:the-same-repository-bound-a-decision-once-and-not-the-other-time
|
||||
evidenceCapturedOn: 2026-09-01
|
||||
assets:
|
||||
- key: the-same-repository-bound-a-decision-once-and-not-the-other-time
|
||||
file: ../../../final/evidence/rendered/the-same-repository-bound-a-decision-once-and-not-the-other-time.svg
|
||||
evidence:
|
||||
- ../../../final/evidence/raw/the-same-repository-bound-a-decision-once-and-not-the-other-time.txt
|
||||
source:
|
||||
- 원본 분석 절은 final/document.md#a20-grpc-codegen §17.4 · final/document.md#a20-grpc-advanced-bootstrap(확인된 설계) 이다.
|
||||
---
|
||||
|
||||
# 같은 저장소가 "결정을 그 결정이 판정한 대상에 묶는 것"을 한 번은 맞게, 한 번은 틀리게 썼다
|
||||
|
||||
두 리프가 판정과 기록을 두 호출로 나눈다. 한쪽은 결정이 자기가 밟고 선 상태를 들고 있어 적용 시점에 대조하고, 다른 쪽은 결정이 무엇을 판정했는지 들고 있지 않아 짝이 어긋날 수 있다.
|
||||
|
||||
## 관계
|
||||
|
||||
- **중복 장치를 찾으면 어느 쪽이 조립됐는지 먼저 확인한다**
|
||||
같은 형태의 장치가 둘일 때 쓰는 규칙이다.
|
||||
- **같은 자격 증명 회전 결함이 한 가족에서 닫히고 다른 가족에서 재현됐다**
|
||||
같은 저장소가 같은 형태를 두 번 다르게 쓴 다른 사례다.
|
||||
- **검증기는 발행이 아니라 주입이 강제다**
|
||||
판정이 실제로 걸리는 지점을 묻는 계열의 규칙이다.
|
||||
|
||||
## 문제
|
||||
|
||||
판정과 기록을 나누면 그 사이를 무엇이 묶는지가 문제가 된다.
|
||||
|
||||
스키마 산출물 발행자는 후보와 소비자 픽스처 목록을 받아 발행 가능 여부를 결정으로 돌려준다. 그리고 그 결정을 들고 다시 오면 이력에 기록한다. 발행 결정은 허용 여부와 차단 사유 목록으로 되어 있다.
|
||||
|
||||
승격 지원 매트릭스도 같은 형태다. 승격 게이트가 증거와 시작 등급과 목표 등급을 받아 결정을 돌려주고, 매트릭스가 그 결정을 받아 적용한다.
|
||||
|
||||
## 결론
|
||||
|
||||
한쪽만 짝을 확인한다.
|
||||
|
||||
승격 매트릭스는 결정의 시작 등급이 현재 등급과 다르면 던진다. 예외 메시지가 그 이유를 적는다. 두 승격이 경합했거나 하나가 재생된 경우라는 것이다. 결정이 자기가 밟고 선 상태를 들고 있고 적용 시점에 그것을 대조한다.
|
||||
|
||||
스키마 발행자는 결정이 허용인지만 본다. 그 결정이 지금 발행하려는 후보를 판정한 것인지 확인하지 않는다. 발행 결정 객체가 허용 여부와 차단 사유만 갖고 있어서 확인할 재료도 없다.
|
||||
|
||||
그래서 무해한 후보를 평가한 결정으로 다른 후보를 발행할 수 있다. 그 후보는 어떤 소비자 픽스처와도 대조되지 않고, 이미 발행된 버전인지도 확인되지 않은 채 이력에 들어간다. 이 클래스가 존재하는 이유인 두 규칙, 즉 소비자 컴파일 게이트와 릴리스 버전 불변성이 인자 짝 하나로 무력해진다.
|
||||
|
||||
테스트의 차이도 같다. 발행자 테스트는 평가와 발행을 한 줄에 겹쳐 써서 규율을 지킨다. 그 규율을 코드가 강제하지 않는다. 매트릭스 쪽에는 어긋난 짝을 넣어 거부를 확인하는 테스트가 따로 있다.
|
||||
|
||||
이 저장소는 올바른 형태를 알고 있고 한 곳에서 쓰지 않았다.
|
||||
|
||||
## 검증 환경
|
||||
|
||||
OpenJDK : 21.0.12
|
||||
Gradle : 9.0.0
|
||||
확인 방식 : 두 적용 메서드의 본문 대조와 결정 객체의 성분 확인
|
||||
소스 수정 : x
|
||||
|
||||
## 재현 조건
|
||||
|
||||
1. 스키마 발행자의 평가 메서드와 발행 메서드가 각각 무엇을 검사하는지 적는다.
|
||||
2. 발행 결정 객체의 성분을 나열한다.
|
||||
3. 승격 매트릭스의 적용 메서드가 결정의 어떤 성분을 현재 상태와 대조하는지 확인한다.
|
||||
4. 두 테스트가 각각 짝을 어떻게 맞추는지 확인한다.
|
||||
|
||||
## 본문
|
||||
|
||||
<!-- body:start -->
|
||||
|
||||
두 리프가 같은 문제를 푼다 — 판정과 기록이 두 호출로 나뉠 때 그 사이를 무엇이 묶는가.
|
||||
|
||||
## PublishDecision 참조 위치
|
||||
|
||||
:::evidence key="the-same-repository-bound-a-decision-once-and-not-the-other-time" alt="코드베이스에서 PublishDecision 를 검색한 출력 4줄. 이 기록이 세는 참조가 그 출력에 그대로 보인다." caption="PublishDecision 코드베이스 검색 — 4줄 · exit 0" zoom="true"
|
||||
:::
|
||||
|
||||
## 묶지 않은 쪽
|
||||
|
||||
`GrpcSchemaArtifactPublisher.publish(candidate, decision)` 는 `decision.allowed()` 만 보고 기록한다. `PublishDecision` 은 `(boolean, List<String>)` 뿐이라 자기가 무엇을 판정했는지 들고 있지 않으므로, A 를 평가한 결정으로 B 를 발행할 수 있고 그러면 소비자 컴파일 게이트와 릴리스 버전 불변성을 둘 다 우회한다. 이 클래스가 존재하는 이유인 두 규칙이 인자 짝 하나로 무력해진다.
|
||||
|
||||
## 묶은 쪽
|
||||
|
||||
`GrpcAdvancedSupportMatrix.apply(decision)` 는 결정의 `from` 이 현재 등급과 다르면 던지고, 그 이유를 "두 승격이 경합했거나 하나가 재생된 경우" 라고 적는다. 결정이 자기가 밟고 선 상태를 들고 있고 적용 시점에 대조하는 형태다.
|
||||
|
||||
## 두 테스트의 차이도 같다
|
||||
|
||||
전자의 테스트는 `publish(artifact, evaluate(artifact, …))` 로 한 줄에서 짝을 맞춰 규율을 지키지만 코드가 그것을 강제하지 않고, 후자는 어긋난 짝을 넣는 테스트가 따로 있다.
|
||||
|
||||
## 확인하지 못한 것
|
||||
|
||||
어긋난 짝을 실제로 실행해 보지 않았다. 판정은 발행 메서드 본문에 대조 코드가 없다는 것에 근거한다.
|
||||
|
||||
<!-- body:end -->
|
||||
-54
@@ -1,54 +0,0 @@
|
||||
---
|
||||
kind: PROJECT_DECISION
|
||||
slug: one-audit-mechanism-per-entity
|
||||
title: 감사 메커니즘은 엔티티당 정확히 하나여야 한다
|
||||
topic: duplicate-mechanisms
|
||||
project: clean-architecture-backend-template
|
||||
status: 게시 전
|
||||
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
|
||||
rootTreeNode: decision:one-audit-mechanism-per-entity
|
||||
decisionStatus: ADOPTED
|
||||
decidedOn: 2026-08-30
|
||||
source:
|
||||
- src/adapter/outbound/persistence-jpa/src/main/java/dev/caskeleton/adapter/outbound/persistence/audit
|
||||
- src/adapter/outbound/persistence-jpa/src/main/java/dev/caskeleton/adapter/outbound/persistence/envers
|
||||
- final/document.md#a05
|
||||
---
|
||||
|
||||
# 감사 메커니즘은 엔티티당 정확히 하나여야 한다
|
||||
|
||||
## 결정문
|
||||
|
||||
한 엔티티의 감사 기록은 하나의 메커니즘이 소유하고, 둘 이상이 같은 엔티티를 기록하지 않는다.
|
||||
|
||||
## 판단 이유
|
||||
|
||||
감사 메커니즘이 둘이면 같은 변경이 두 번 기록되거나, 두 기록이 서로 다른 내용을 담거나, 둘 중 하나만 도는데 어느 쪽인지 알 수 없게 된다.
|
||||
|
||||
세 결과 모두 감사의 목적을 무너뜨린다. 감사 기록은 나중에 사람이 판단의 근거로 쓰는 것이고, 근거가 둘이면 판단이 서지 않는다.
|
||||
|
||||
그리고 감사는 조용히 실패하는 계열이다. 기록이 남지 않아도 업무 트랜잭션은 성공하므로, 두 메커니즘 중 하나가 꺼져 있어도 증상이 없다.
|
||||
|
||||
그래서 소유권을 엔티티 단위로 정한다. 어떤 엔티티가 어떤 메커니즘의 소유인지가 한 곳에서 결정되고, 그 결정이 코드로 확인 가능해야 한다.
|
||||
|
||||
## 영향
|
||||
|
||||
감수하는 것
|
||||
|
||||
메커니즘마다 다른 능력을 갖는데 엔티티는 하나만 고를 수 있다. 이력 조회가 필요한 엔티티와 변경 시각만 필요한 엔티티가 같은 선택지를 공유하지 않는다.
|
||||
|
||||
메커니즘을 바꾸면 그 엔티티의 과거 기록과 새 기록이 다른 형태가 된다.
|
||||
|
||||
얻는 것
|
||||
|
||||
한 변경에 대한 감사 기록이 정확히 하나다.
|
||||
|
||||
메커니즘 하나가 배선되지 않았을 때 그 엔티티의 기록이 통째로 비므로, 부분적으로만 기록되는 상태보다 발견하기 쉽다.
|
||||
|
||||
## 근거
|
||||
|
||||
- **같은 개념의 두 어휘가 공존하면 하나를 죽은 것으로 표시한다**
|
||||
이 결정이 속한 계열의 규칙이다.
|
||||
- **중복 장치를 찾으면 어느 쪽이 조립됐는지 먼저 확인한다**
|
||||
중복이 이미 있을 때의 확인 절차다.
|
||||
|
||||
-55
@@ -1,55 +0,0 @@
|
||||
---
|
||||
kind: REFERENCE
|
||||
slug: two-vocabularies-for-one-concept
|
||||
title: 같은 개념의 두 어휘가 공존하면 하나를 죽은 것으로 표시한다
|
||||
topic: duplicate-mechanisms
|
||||
project: clean-architecture-backend-template
|
||||
status: 게시 전
|
||||
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
|
||||
rootTreeNode: reference:two-vocabularies-for-one-concept
|
||||
verifiedOn: # 이 기록은 이번 회차에 실행 확인을 하지 않았다
|
||||
---
|
||||
|
||||
# 같은 개념의 두 어휘가 공존하면 하나를 죽은 것으로 표시한다
|
||||
|
||||
## 목적
|
||||
|
||||
같은 개념을 가리키는 이름이 둘 남아 있어, 다음 사람이 어느 쪽이 정본인지 모른 채 둘 다 유지하거나 잘못된 쪽을 고치는 것을 막는다.
|
||||
|
||||
## 규칙
|
||||
|
||||
1. 정본을 명시한다
|
||||
두 어휘 중 어느 쪽이 앞으로 쓰일 이름인지 코드나 문서에 적는다.
|
||||
|
||||
2. 죽은 쪽에 표시를 남긴다
|
||||
지울 수 없다면 그것이 유지되지 않는 이름이라는 것과 언제 지울 수 있는지를 적는다.
|
||||
|
||||
3. 표시가 없으면 둘 다 살아 있는 것으로 읽힌다
|
||||
이름이 남아 있는 것 자체가 의도로 읽힌다.
|
||||
|
||||
4. 이름이 다른 계층에 걸쳐 있으면 매핑을 한 곳에 둔다
|
||||
변환이 여러 곳에 흩어지면 그중 하나가 뒤처진다.
|
||||
|
||||
## 적용 조건
|
||||
|
||||
리팩터링이나 계층 재배치 뒤 남은 옛 이름
|
||||
|
||||
같은 도메인 개념을 어댑터와 애플리케이션이 다르게 부르는 경우
|
||||
|
||||
## 예외
|
||||
|
||||
외부 계약이 옛 이름을 요구하면 그 이름은 죽은 것이 아니라 경계 어휘다. 그 사실이 경계 지점에 적혀 있어야 한다.
|
||||
|
||||
## 예시
|
||||
|
||||
이 저장소에는 미완성 상태에 이름을 붙이고 기동에서 거절하며 그 이름이 언제 목록에서 빠지는지까지 적은 선례가 있다. 그 항목은 자기 전송이 존재하는 날 이 맵을 떠난다고 적혀 있다.
|
||||
|
||||
반대로 구현 계획에만 남은 클래스 이름이 ADR 의 강제 절에 그대로 인용되어, 그 절을 읽으면 존재하지 않는 것이 강제하고 있다고 읽힌다.
|
||||
|
||||
## 관계
|
||||
|
||||
- **재시도 코디네이터는 빈이지만 그것을 어디에도 적용하지 않는다**
|
||||
문서에만 남은 이름이 강제 수단으로 인용된 사례다.
|
||||
- **중복 장치를 찾으면 어느 쪽이 조립됐는지 먼저 확인한다**
|
||||
같은 계열의 확인 규칙이다.
|
||||
|
||||
Reference in New Issue
Block a user