102 lines
4.5 KiB
YAML
102 lines
4.5 KiB
YAML
schema-version: 1
|
|
sections:
|
|
- id: overview
|
|
title-guidance: 템플릿 개요
|
|
level: 2
|
|
purpose: 가치 제안, 대상 독자, 적합하거나 부적합한 사용 상황을 빠르게 판단시킨다.
|
|
required: true
|
|
content-strategy: inline
|
|
content-requirements:
|
|
- Java와 Spring Boot 기준 버전
|
|
- 권고가 아닌 실행 가능한 경계 검증이라는 차별점
|
|
- 참조 템플릿이라는 정직한 포지셔닝
|
|
visual-slot:
|
|
decision: exclude
|
|
reader-question: 이 프로젝트의 정체성을 이해하는 데 그림이 필요한가?
|
|
rationale: 짧은 가치 제안과 적합성 목록이 더 빠르고 정확하다.
|
|
- id: project-value
|
|
title-guidance: 제공 가치와 결정 영역
|
|
level: 2
|
|
purpose: 저장소가 자동으로 강제하는 것과 도입자가 선택할 것을 분리한다.
|
|
required: true
|
|
content-strategy: inline
|
|
content-requirements:
|
|
- 아키텍처·잠금·샘플 격리 계약
|
|
- 도메인·adapter·배포 정책은 도입자 책임임을 명시
|
|
visual-slot:
|
|
decision: exclude
|
|
reader-question: 강제 영역과 선택 영역을 어떻게 가장 빨리 비교하는가?
|
|
rationale: 두 열 비교표가 그림보다 직접적이고 접근성이 높다.
|
|
- id: architecture
|
|
title-guidance: 아키텍처와 코드 배치
|
|
level: 2
|
|
purpose: core, adapter, composition root의 관계와 코드 변경 위치를 설명한다.
|
|
required: true
|
|
content-strategy: inline
|
|
content-requirements:
|
|
- 의존 방향 Mermaid 다이어그램
|
|
- 모듈 그룹별 책임 표
|
|
- Gradle과 ArchUnit이 각각 검증하는 경계
|
|
visual-slot:
|
|
decision: include
|
|
reader-question: 여러 모듈 그룹이 어느 방향으로 의존하는가?
|
|
rationale: 다섯 구성요소의 의존 방향은 문장 나열보다 흐름도가 더 빨리 전달한다.
|
|
purpose: adapter와 composition root가 core 방향으로 의존한다는 구조를 한 화면에 보여준다.
|
|
- id: quick-start
|
|
title-guidance: 빠른 시작
|
|
level: 2
|
|
purpose: 사전 조건, 단일 bootstrap 명령, 부작용, 성공 신호와 정리 방법을 제공한다.
|
|
required: true
|
|
content-strategy: inline
|
|
content-requirements:
|
|
- JDK 21과 Docker
|
|
- bootstrap 실행 명령
|
|
- API health 성공 조건
|
|
- Compose 정리 명령
|
|
visual-slot:
|
|
decision: exclude
|
|
reader-question: 실행 절차를 이해하는 데 추가 시각 자료가 필요한가?
|
|
rationale: 짧은 명령 블록과 성공 조건이 가장 실행 가능하다.
|
|
- id: adoption
|
|
title-guidance: 실제 프로젝트로 전환하기
|
|
level: 2
|
|
purpose: 프로젝트 식별자, 도메인, adapter, 환경 정책, sample 제거 순서로 도입 경로를 안내한다.
|
|
required: true
|
|
content-strategy: inline
|
|
content-requirements:
|
|
- sample은 참조 구현이며 production 의존성이 아님
|
|
- sampleOffTest를 이용한 제거 검증
|
|
- 상세 문서를 중복하지 않는 단계별 전환 경로
|
|
visual-slot:
|
|
decision: exclude
|
|
reader-question: 도입 순서는 어떤 형태가 가장 행동하기 쉬운가?
|
|
rationale: 번호 목록과 검증 체크포인트가 진행 순서를 명확히 한다.
|
|
- id: verification
|
|
title-guidance: 검증 루프
|
|
level: 2
|
|
purpose: 빠른 테스트, 아키텍처 경계, 샘플 제거, 전체 check의 목적과 명령을 분리한다.
|
|
required: true
|
|
content-strategy: inline
|
|
content-requirements:
|
|
- test와 architecture 명령
|
|
- sampleOffTest 명령
|
|
- 전체 check가 집계하는 정책
|
|
visual-slot:
|
|
decision: exclude
|
|
reader-question: 검증 수준별 명령 선택에 그림이 필요한가?
|
|
rationale: 목적과 명령을 짝지은 표가 더 정확하다.
|
|
- id: documentation
|
|
title-guidance: 상세 문서 지도와 한계
|
|
level: 2
|
|
purpose: 빌드·모듈·환경·운영 문서로 이동시키고 템플릿의 적용 한계를 명시한다.
|
|
required: true
|
|
content-strategy: inline
|
|
content-requirements:
|
|
- src README와 대표 모듈 README 링크
|
|
- 환경 레지스트리와 runbook 링크
|
|
- 조직별 비기능 요구사항은 별도 검증이라는 한계
|
|
visual-slot:
|
|
decision: exclude
|
|
reader-question: 세부 문서 위치를 찾는 데 그림이 필요한가?
|
|
rationale: 목적별 링크 목록이 탐색과 유지보수에 적합하다.
|