DongHyeonkaandClaude Fable 5.1
b25357c48a
- analysis/·source-index·state.json 을 final/document.md 제2부·제3부로 접었다. SSOT 는 하나다 - 파일럿 — commit-ambiguity-as-a-result 를 새 기준으로 재선별. 후보 14 → 글감 5 (PROMOTE 5 · MERGE_INTO 3 · KEEP_IN_SSOT 4 · 보류 2). 기록 5건을 다시 썼고 그림 1개를 techviz 로 만들었다 - 재선별이 잡은 것: 제1부 §6.2·§11.1 이 자기 §13.2 와 어긋나 있었다(레인을 안 돌렸다 vs 돌렸다) — 정정. 이미 답이 나와 있던 Question 을 HEAD 재실행 질문으로 다시 세웠다. Concept 이 인용한 코드가 SSOT 에 없어 뺐다 - candidateScope·sourceRepository 기록. 나머지 43개 주제는 재선별 대기(PENDING 905) Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
3.9 KiB
kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, evidenceCapturedOn, assets, evidence, source, module
| kind | slug | title | topic | project | status | sourceRevision | rootTreeNode | evidenceCapturedOn | assets | evidence | source | module | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CONCEPT | application-core-c01 | application-core가 아는 유일한 프로젝트 의존은 shared-contract다 | query-and-pagination-models | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | concept:application-core-c01 | 2026-09-01 |
|
|
|
application-core |
application-core가 아는 유일한 프로젝트 의존은 shared-contract다
build.gradle의 production project dependency는 :shared-contract 하나뿐이다. 실행 정책은 use case 타입이 아니라 @UseCaseCapability에 선언되고, CleanArchitectureTest가 그 선언과 실제 호출의 일치를 검사한다.
관계
- legacy storage/notification compatibility surface의 제거 조건 추적 같은 분석 리프에서 끌어낸 규칙이다.
본문
Observed. build.gradle의 production project dependency는 :shared-contract 하나뿐이다. application-core가 Spring, JPA, Redis, Kafka, filesystem provider 같은 구현 모듈을 직접 참조하지 않고, 외부 구현은 composition root와 adapter가 역으로 이 모듈의 port를 구현한다.
의존이 흐르는 방향
:::evidence key="application-core-c01-diagram" alt="어댑터와 application-core 와 shared-contract 가 위에서 아래로 쌓이고 의존 방향 화살표가 아래쪽 하나로만 그려진 구조" caption="의존이 흐르는 한 방향" zoom="false" :::
실행 정책은 애너테이션에 따로 선언된다
CommandUseCase<C extends Command,R>와 QueryUseCase<Q extends Query,R>는 UseCase<I,O>.handle(I)를 write/read intent에 맞게 타입으로 좁힌다. 자체적으로 transaction을 열거나 security interceptor를 실행하지 않는다. 실행 정책은 @UseCaseCapability에 별도로 선언된다 — runtime TYPE annotation이며 transactionMode, idempotency, repositoryAccess를 필수로 받고 externalOutboundAllowed, sensitiveRead, bulkWrite, crossTenantAdmin을 추가 선언한다.
CleanArchitectureTest 참조 위치
:::evidence key="application-core-c01" alt="코드베이스에서 CleanArchitectureTest 를 검색한 출력 6줄. 이 기록이 세는 참조가 그 출력에 그대로 보인다." caption="CleanArchitectureTest 코드베이스 검색 — 6줄 · exit 0" zoom="true" :::
적합성 함수가 검사하는 일곱 가지
annotation 자체는 metadata에 불과하지만 CleanArchitectureTest가 concrete Command/Query use case에 annotation 존재를 강제한다. 그 위에서 architecture fitness function이 다음 coherence를 직접 검사한다.
READ_ONLY + READ_REPOSITORY는TransactionPort.inRead를 직접 호출해야 한다.WRITE + WRITE_REPOSITORY는inWrite또는inRootWrite를 직접 호출해야 한다.REQUIRES_NEW는inNew를 직접 호출해야 한다.repositoryAccess != WRITE_REPOSITORY인 use case가 repository write verb를 직접 호출하면 실패한다.bulkWrite=true는WRITE_REPOSITORY를 요구한다.- mutating use case는 type-level
@RequiresPermission을 선언해야 한다. - application/domain은 Spring Security에 의존할 수 없다.
이 강제가 잡지 못하는 것
이 enforcement에는 의도적으로 한계가 있다. ArchUnit의 direct-call 분석이므로 helper 뒤에 숨은 repository mutation/transaction call은 잡지 못하고, AOP self-invocation/non-bean path도 static rule만으로 보장하지 않는다. 이 제한은 테스트 설명 자체에 명시돼 있어 최종 계약의 일부로 봐야 한다.