CLAUDE CODE ADAPTER · VERSION 1.1 · MARCH 2026

AI-Driven Java Application
Development Methodology

A-ADM Core 방법론의 Claude Code + Java 21 구현 어댑터.
Spring Boot 3.x · 헥사고날 아키텍처 · 12개 슬래시 커맨드로 SDLC 전 단계를 자동화합니다.

5
SDLC 단계
7
SKILL.md 파일
3
계약 파일
12
슬래시 커맨드
A-ADM 시리즈
● A-JADM Java · A-GADM Go Backend · A-FADM Frontend · React/TypeScript

A-JADM이란

A-JADM은 A-ADM Core의 Claude Code 구현 어댑터입니다.
Java 21 + Spring Boot + 아키텍처 (헥사고널 | 레이어드) 스택으로,
SKILL.md 7개와 슬래시 커맨드 12개로 SDLC 전 단계를 자동화합니다.

A-ADM CORE 참조

이 문서는 A-ADM CoreClaude Code + Java 21 구현 어댑터입니다.
설계 원칙 · 계약 파일 스키마 · 추적성 규칙 · Wave 토폴로지 등 방법론 본질은 Core 문서를 참조하세요.

A-ADM Core 보기 → 이 어댑터 고유 내용: SKILL.md 구현 · 12개 슬래시 커맨드 · Java 21 고정 스택 · 테스트 피라미드
Lean
필요한 것만 정확하게
추적
UC → 코드 → 테스트 1:1
계약
파일 기반 스킬 연결
반복
BC 단위 점진적 구현

A-FADM과의 연결 구조

A-FADM 문서 보기 →

A-JADM은 백엔드 파이프라인을 담당하고, A-FADM은 프론트엔드(React/TypeScript) 파이프라인을 담당합니다. 두 방법론의 연결 지점은 /gen-openapi 커맨드가 생성하는 openapi.yaml입니다.

[ A-JADM — 백엔드 파이프라인 ]
/usecase → /ddd-modeling → /arch-design → /implement-bc → /gen-test → /run-local
                                                                           │
                                                          /gen-openapi → openapi.yaml   ← 연결 지점
                                                                           │
[ A-FADM — 프론트엔드 파이프라인 시작 ]
openapi.yaml → /fe-spec → /fe-scaffold → /fe-implement → /fe-test
백엔드 API 명세 확정 전에도 openapi.yaml 초안을 기반으로 프론트엔드 파이프라인을 병렬로 진행할 수 있습니다.

세 가지 핵심 축

스킬 (Skill)
재사용 가능한 프롬프트 모듈
SKILL.md 오케스트레이터 + 참조 파일 구조. 세션마다 재작성하지 않고 커맨드 한 줄로 일관된 산출물 생성.
계약 파일 (Contract)
스킬 간 인터페이스
domain-context.md · arch-decisions.md · bc-plan.md. 스킬이 서로를 직접 호출하지 않고 파일로 소통.
슬래시 커맨드
자동화 실행 단위
CLAUDE.md에 정의된 /implement-bc, /gen-test 등. 계약 파일을 읽어 추론 없이 결정적으로 실행.

전통 개발 → AI-Driven 개발

A-ADM의 핵심 패러다임 전환과 계약 파일이 필요한 이유는 A-ADM Core 문서에 상세히 설명되어 있습니다.
이 섹션에서는 Claude Code 환경에서의 실제 적용 포인트를 정리합니다.

🎯

SKILL.md 오케스트레이터

각 스킬은 SKILL.md 파일 하나로 완결됩니다. Claude Code가 파일을 읽고 실행 — 세션마다 프롬프트 재작성 불필요.

📄

계약 파일 자동 검증

domain-context.md가 없으면 스킬이 즉시 중단합니다. 계약 없는 추론 실행은 허용되지 않습니다.

슬래시 커맨드 자동화

CLAUDE.md에 정의된 12개 커맨드로 SDLC 전 단계를 한 줄로 실행. BC 단위 점진적 구현이 기본 전략입니다.

5대 설계 원칙

5대 원칙의 전체 정의는 A-ADM Core → 설계 원칙을 참조하세요.
Claude Code 어댑터 관점에서의 적용 방식을 정리합니다.

① Lean
CLAUDE.md 4개 값 변경으로 배포

company, domain, base-package, java-version만 바꾸면 새 프로젝트에 즉시 적용됩니다.

② Traceability
@Test 메서드명 = Gherkin 제목

gen-test 스킬이 시나리오 ID 주석과 1:1 @Test를 자동 생성합니다.

③ Contract-File
파일 없으면 스킬 중단

arch-decisions.md 없이 /implement-bc를 실행하면 즉시 에러. 추론 모드 폴백 없음.

④⑤ Convergence + Scale
병렬 스킬 + Wave 분해

usecase-by-example ∥ ddd-modeling 수렴 후 bc-plan.md Wave 순서로 구현.

FIXED STACK Java 21 Spring Boot 3.x Hexagonal | Layered JPA (Command) + jOOQ (Query) JUnit 5 + AssertJ Mockito + Testcontainers Lombok 금지

5단계 워크플로

요구사항 분석부터 실행까지, 각 단계는 명확한 입력·산출물·게이트를 가집니다.

1
요구사항 분석
/usecase → /usecase-by-example 순차 파이프라인
도메인 설명 (자연어)
       │
       ▼
/usecase [--level casual|fully-dressed]    ← Step 1
       │
       ▼
UC명세서.md                             ← 검토·수정 후 다음 단계
       │
       ▼
/usecase-by-example                   ← Step 2
       │
       ▼
*.feature                                  ← Phase 2 ddd-modeling 입력
1
/usecase — UC 명세서 작성 (Usecase 2.0)
도메인 설명을 입력받아 구조화된 UC 명세서를 생성한다.
--level 분량 용도
brief2~5줄파이프라인 사용 금지
casual~1페이지기본값 — 내부 팀용
fully-dressed3~5페이지외부 이해관계자·복잡 예외
산출 항목: 기본 흐름(번호별 스텝) + 대안 흐름 + 예외 흐름 + 비기능 요구사항
2
/usecase-by-example — Gherkin 시나리오 변환
UC명세서.md를 읽어 .feature 파일로 변환한다.
UC명세서.md가 없으면 중단하고 /usecase 실행을 안내한다.
UC 명세서 항목 Gherkin 변환
사전조건Given
기본 흐름 행위 (액터)When
기본 흐름 응답 (시스템)Then
대안 흐름Scenario 추가
예외 흐름에러 케이스 Scenario
산출물
📄 UC명세서.md (검토 대상)
📄 *.feature (Gherkin 시나리오)
→ Phase 2 ddd-modeling + usecase-by-example 입력
파이프라인 연결 규칙
기본 흐름 Step N → When 절 행위 N으로 1:1 매핑
예외 흐름 E1, E2 → 에러 Scenario로 변환
brief 수준은 파이프라인 사용 금지 — 정보 부족으로 Gherkin 변환 불가
2
설계
ddd-modeling · arch-design · uc-to-skeleton (병렬 → 수렴 → 직렬)
1
도메인 모델링 (병렬 실행)
ddd-modeling: BC 식별 → Aggregate → Command/Event → UL. usecase-by-example과 수렴 체크.
2
아키텍처 구조화 (arch-design)
모듈(single/multi) · web(mvc/webflux) · persistence(jpa / jpa+jooq / jdbc) · messaging 확정.
jpa+jooq: Command Side = JPA, Query Side = jOOQ (CQRS).
Lombok 금지 규칙 적용.
3
스켈레톤 생성 (uc-to-skeleton)
domain-context.md + arch-decisions.md → 클래스/패키지 스켈레톤 + PlantUML 시퀀스 다이어그램.
추론 없는 1:1 매핑.
수렴 조건 (게이트)
UL ↔ Gherkin 용어 일치
Aggregate 상태 ↔ Given/When/Then 일치
미통과 시 ddd-modeling 재실행
계약 파일 산출
📋 domain-context.md
📋 arch-decisions.md
3
구현
/implement-bc · CLAUDE.md · BC 단위 반복
1
구현 전략 수립
bc-plan.md Wave 위상 정렬.
Core Domain BC 우선.
도메인 → 애플리케이션 → 어댑터 레이어 순서.
2
BC 단위 구현 (/implement-bc)
Wave 0 (shared) → Wave 1 → Wave 2(병렬 가능) → Wave 3.
각 Wave Gate 통과 후 진행.
3
고정 코딩 규칙 (Java 21 + Spring Boot 3)
Lombok 금지.
DTO·VO·Event → Record. Entity → 정적 팩토리.
DI → 명시적 생성자.
레이어 구현 순서 (arch-decisions.md 선택)
Hexagonal (권장)
domain — Aggregate, VO(record), Event(record), Port
application — UseCase, Command(record), Service
adapter — Controller, JpaEntity/JdbcRow, Adapter
Layered
domain — Entity, VO, Repository 인터페이스
service — 비즈니스 로직, 트랜잭션 경계
web — Controller, DTO
infrastructure — JpaRepository, 외부 연동
Wave Gate
mvn compile → mvn test
4
테스트
/gen-test · Gherkin 1:1 추적 · 테스트 피라미드 전략
테스트 피라미드 — 레이어별 비중 및 커버리지 목표
50%
domain
목표 ≥ 90%
JUnit 5 + AssertJ
25%
application
목표 ≥ 80%
JUnit 5 + Mockito
20%
adapter
목표 ≥ 70%
@WebMvcTest · @DataJpaTest
5%
E2E
시나리오 100%
Testcontainers
domain
JUnit 5 + AssertJ
Aggregate 불변식
VO 동등성 · 상태 전이
application
JUnit 5 + Mockito
Port → Mock 대체
이벤트 발행 verify
adapter
@WebMvcTest (web)
@DataJpaTest (jpa)
Testcontainers (jdbc)
PBT
Property-Based Testing
/gen-test --pbt
Aggregate 불변식이 임의 입력에 대해서도 성립하는지 Jqwik으로 자동 탐색.
도메인 레이어에만 적용.
@Property — 불변식 위반 경계값 자동 탐색
@ForAll @Positive — 수치 범위 제약 자동 적용
Arbitrary<T> — 복합 도메인 객체 생성기
계약
BC 간 계약 테스트
/gen-test --contract
arch-decisions.md의 messaging 파라미터를 읽어 도구를 자동 선택.
동기 ACL
Spring Cloud Contract
서버 측 스텁 자동 생성
비동기 Kafka
Pact
Consumer-Driven 계약
피드백 루프: 테스트 실패 원인이 요구사항이면 Phase 1, 도메인 모델이면 Phase 2, 구현이면 Phase 3으로 역추적합니다.
PBT 반례(counterexample)는 발견된 불변식 위반 입력값을 Jqwik이 자동으로 최소화(shrinking)하여 리포트합니다.
5
실행
/run-local · /run-check · Docker Compose · 프로파일 분리
1
/run-local — 로컬 실행 환경 기동
arch-decisions.md를 읽어 필요한 인프라(DB, Kafka, Redis 등)를 Docker Compose로 기동한 뒤 Spring Boot 애플리케이션을 시작한다.
--profile local 자동 적용.
2
/run-check — 실행 상태 검증
기동된 애플리케이션의 헬스 엔드포인트, DB 커넥션, BC 간 포트 연결, 메시지 브로커 토픽 존재 여부를 순서대로 확인하고 결과를 보고한다.
3
application.yml 프로파일 체계
local — Docker Compose 인프라, 디버그 로그.
test — Testcontainers 자동 기동, 격리 DB.
prod — 외부 인프라 연결, 최소 로그.
프로파일별 인프라 구성
프로파일 DB Kafka 기동 방법
localDockerDockerdocker compose up
testTCTCmvn verify 시 자동
prod외부외부환경 변수 주입
TC = Testcontainers 자동 기동
Run Gate (실행 완료 조건)
GET /actuator/health → 200 OK
✅ DB 커넥션 풀 정상
✅ BC 간 OutputPort 구현체 주입 확인
✅ messaging ≠ none → 토픽 존재 확인

Docker Compose 구성 — arch-decisions.md 기반 자동 생성

persistence=jpa
services:
  postgres:
    image: postgres:16-alpine
    ports: ["5432:5432"]
    environment:
      POSTGRES_DB: appdb
messaging=kafka
services:
  kafka:
    image: bitnami/kafka:3.7
    ports: ["9092:9092"]
    environment:
      KAFKA_CFG_NODE_ID: 0
application.yml
spring:
  profiles:
    active: local
  datasource:
    url: jdbc:postgresql://
      localhost:5432/appdb
jOOQ (persistence=jpa+jooq) 사용 시 추가 사항
jOOQ는 별도 인프라 불필요 — postgres 컨테이너는 동일하게 사용.
빌드 타임에 /gen-schema 산출물(schema.sql)을 jOOQ codegen이 읽어 Java 클래스 자동 생성.
pom.xml에 jOOQ codegen 플러그인 추가 필요 (arch-decisions.md 기반 자동 구성).
피드백 루프: Run Gate 실패 시 —
DB 연결 오류이면 Phase 3 adapter 수정, 포트 주입 실패이면 Phase 3 서비스/application 레이어, 토픽 미생성이면 /run-local 재실행.

각 스킬은 프로젝트 루트의 .claude/skills/ 디렉토리에 SKILL.md 파일로 저장됩니다.
슬래시 커맨드 실행 시 Claude Code가 해당 파일을 읽고 계약 파일을 참조하여 산출물을 생성합니다.
세션 간 상태 유지는 계약 파일이 담당하므로 스킬 자체는 무상태(stateless)입니다.

7개 스킬 파이프라인

각 스킬은 독립적인 SKILL.md 오케스트레이터 + 참조 파일로 구성됩니다.
Phase 1은 순차 파이프라인, Phase 2 이후는 계약 파일로만 소통합니다.

usecase 2.0 usecase-by-example ⇅ 수렴 ddd-modeling arch-design nfr-spec uc-to-skeleton
usecase 2.0

UC 명세서 작성 스킬

도메인 설명을 Usecase 2.0 형식의 구조화된 명세서로 작성.
수준(--level)에 따라 Brief / Casual / Fully-dressed 산출.

입력: 도메인 설명 (자연어) / 산출: UC명세서.md
brief는 파이프라인 사용 금지 — Gherkin 변환에 정보 부족
기본값: --level casual
usecase-by-example

SBE 시나리오 스킬

UC명세서.md를 읽어 Gherkin .feature 파일로 변환.
ddd-modeling과 병렬 실행 후 수렴 체크.

입력: UC명세서.md / 산출: *.feature
ddd-modeling

DDD 도메인 모델링 스킬

Step 1 BC 식별 → Step 2 Aggregate 설계 → Step 3 Command/Event 매핑 → Step 4 UL 사전 + 수렴 검증.

입력: UC명세서+.feature / 산출: domain-context.md
arch-design

아키텍처 설계 스킬

Step 1 모듈 구조 → Step 2 BC 간 통신 → Step 3 어댑터 구조 → Step 4 공유 커널 위치.
Lombok 금지 규칙 포함.

핵심 파라미터
architecture: hexagonal | layered — 레이어 구조 결정
module: single | multi — Maven 모듈 분리 여부
persistence: jpa | jpa+jooq | jdbcjpa+jooq = Command(JPA) + Query(jOOQ) CQRS
입력: domain-context.md / 산출: arch-decisions.md
nfr-spec

비기능 요구사항 명세 스킬

성능·보안·가용성·운영성 4개 카테고리를 대화로 도출하고 arch-decisions.md의 ## NFR 섹션을 채운다.
코드 생성 지시를 AUTO(자동 생성)와 TODO(태그 주석)로 분류.

입력: arch-decisions.md / 산출: arch-decisions.md (NFR 섹션 추가)
AUTO: JWT·BCrypt·MDC·Actuator·Pageable TODO: Redis·Circuit Breaker·Retry
uc-to-skeleton

스켈레톤 생성 스킬

두 계약 파일을 입력으로 클래스/패키지 스켈레톤과 PlantUML 시퀀스 다이어그램 생성.
NFR AUTO 항목 클래스 포함. 추론 없는 1:1 매핑.

입력: domain-context.md + arch-decisions.md (NFR 섹션 포함)
계약 파일의 YAML 스키마 정의A-ADM Core → 스키마를 참조하세요.
이 섹션은 Claude Code 환경에서의 파일 간 흐름과 소비자 커맨드를 설명합니다.

계약 파일 체계

스킬 간 인터페이스를 파일로 명문화합니다.
소비자 커맨드는 파일 없이는 추론 모드로 실행하지 않습니다.

domain-context.md
ddd-modeling 산출
BC → 패키지 경로 확정
Aggregate Root → 도메인 클래스명
Value Object → 파라미터/반환 타입
Command → 서비스 메서드명
불변식 → 생성자 주석
소비자: arch-design · uc-to-skeleton · implement-bc · gen-test
arch-decisions.md
arch-design 산출 + nfr-spec 보완
module → import 경로, pom.xml
web → Controller 기반 클래스
persistence (jpa) → JpaRepository + @Entity 구현체
persistence (jpa+jooq) → JPA(Command) + jOOQ DSL(Query) 분리
messaging → Event Publisher/Listener
공유 커널 → shared VO import
## NFR → AUTO/TODO 코드 생성 지시 (nfr-spec 추가)
소비자: uc-to-skeleton · implement-bc
bc-plan.md
개발자 작성 (멀티 BC)
Wave 정의 → 구현 순서
depends-on → 순환 의존 검사
output-ports → ACL/Event 결정
communications → 통신 매핑표
shared-kernel → VO 위치 확정
소비자: implement-bc · gen-test

파일 간 흐름

도메인 설명 (자연어)
       ↓
/usecase [--level]  → UC명세서.md        ← 검토·수정 대상
       ↓
/usecase-by-example → *.feature           ← ddd-modeling 입력
       ↓
domain-context.md   ← ddd-modeling 산출 (BC·Aggregate·Command·Event·UL)
       ↓
arch-decisions.md   ← arch-design 산출  (모듈·스택·어댑터·공유커널)
       ↓
arch-decisions.md   ← nfr-spec 보완     (## NFR: AUTO/TODO 코드 생성 지시)
       ↓
gen-schema        (erd.mmd + schema.sql — Aggregate→JpaEntity 매핑)
       ↓
bc-plan.md          ← 개발자 작성       (Wave·통신·순환검사)
       ↓
Java 스켈레톤       ← uc-to-skeleton   (추론 없는 1:1 매핑 + NFR AUTO 클래스)
       ↓
BC별 구현           ← /implement-bc    (Wave 순서대로 + NFR TODO 주석 삽입)
       ↓
테스트 스위트       ← /gen-test        (Gherkin 1:1 추적)
Wave 토폴로지 원칙과 통신 패턴(동기 ACL / 비동기 Event)은 A-ADM Core → 멀티 BC를 참조하세요.
이 섹션은 Java/Spring 환경에서의 구체적 구현 예시를 다룹니다.

멀티 BC 오케스트레이션

여러 Bounded Context를 가진 프로젝트의 구현 순서, BC 간 통신, 공유 커널을 체계적으로 관리합니다.

Wave 위상 정렬 — 쇼핑몰 5 BC 예시

WAVE 0
shared
Money · Address
WAVE 1
inventory
재고 관리
WAVE 2 — 병렬
order
Core Domain
payment
결제 처리
WAVE 3
notification
알림 발송

동기 ACL 패턴

즉각 응답이 필요한 BC 간 호출.
포트 인터페이스는 호출 BC의 application 레이어에 선언, 구현체는 구현 BC의 adapter 레이어에 위치. (Hexagonal 아키텍처 기준)
pom.xml에서 상호 직접 참조 없음.

// order/application/port/output/
public interface InventoryPort {
    void checkStock(ProductId id, int qty);
}

// inventory/adapter/outbound/
public class InventoryPortAdapter
    implements InventoryPort { ... }

비동기 Event 패턴

결과적 일관성으로 충분한 BC 간 통신.
Domain Event를 Kafka/RabbitMQ/Spring Events로 발행.
수신 BC는 ACL Translator로 자신의 도메인 모델로 변환.

// order → OrderPlaced → Kafka
// notification이 order.placed 구독

@KafkaListener(topics = "order.placed")
public void onOrderPlaced(
    OrderPlacedMessage msg) { ... }

Wave Gate — 전환 조건

컴파일 통과
mvn compile
🔌
포트 연결
구현체 존재 확인
🧪
도메인 테스트
mvn test -pl domain
🚫
순환 없음
DFS 사이클 검사
버전 번호 체계(MAJOR/MINOR/PATCH)와 영향 매트릭스는 A-ADM Core → 버저닝을 참조하세요.
이 섹션은 Claude Code 환경에서의 /check-domain-version 커맨드 동작을 설명합니다.

domain-context.md 버저닝

도메인 모델 변경이 어떤 산출물에 영향을 주는지 정확히 추적합니다.
불필요한 전체 재생성을 방지합니다.

버전 번호 체계

M
MAJOR — 전면 재생성
BC 추가/삭제,
Aggregate Root 이름 변경,
Command 이름 변경.
영향 BC 스켈레톤 전체 재생성 필요.
m
MINOR — 부분 재생성
새 Command/Event/VO 추가.
affected-bcs의 특정 레이어만 재생성.
p
PATCH — 재생성 불필요
불변식 설명 수정,
UL 문구 보완,
Gherkin 매핑 수정.
@DisplayName 자동 패치만 적용.

Meta 헤더 (v2 스키마)

## Meta
schema-version: 2.0
content-version: 2.1.0
generated-at: 2026-03-17T09:00:00+09:00
generated-by: ddd-modeling
last-changed-section: Commands
change-type: minor

consumers:
  arch-design:    "2.1.0"   # ✅ 최신
  uc-to-skeleton: "2.0.0"   # ⚠ 재생성 필요
  implement-bc:
    order:        "2.0.0"   # ⚠ 서비스/application 레이어
    payment:      "2.1.0"   # ✅ 최신
  gen-test:       "2.0.0"   # ⚠ 재생성 필요

변경 유형 × 소비자 영향 매트릭스

변경 유형change-typearch-designuc-to-skeletonimplement-bcgen-test
BC 추가/삭제major전면 재실행전체 BCbc-plan 재검토전체 재생성
Aggregate Root 이름 변경major불필요해당 BC 전체도메인 레이어해당 BC 전체
Command 이름 변경major불필요해당 BC 전체서비스 레이어해당 BC 전체
새 Command/Event 추가minor불필요영향 BC만서비스 레이어영향 BC만
VO 추가minor불필요domain만domain만domain 테스트
불변식 설명 수정patch불필요주석만불필요불필요
UL·Gherkin 문구 수정patch불필요불필요불필요@DisplayName만
/check-domain-version 커맨드가 consumers 섹션을 읽어 동기화가 필요한 소비자와 최소 재실행 순서를 자동 계산합니다.
CLAUDE CODE ADAPTER 고유 내용

슬래시 커맨드는 A-ADM Core의 5단계 워크플로를 Claude Code 환경에서 실행하는 진입점입니다.
CLAUDE.md에 정의하며, 다른 AI 도구 어댑터에서는 동등한 트리거 메커니즘으로 대체합니다.

슬래시 커맨드 레퍼런스

CLAUDE.md에 정의된 커맨드가 전 단계를 자동화합니다.
모든 커맨드는 계약 파일을 읽어 추론 없이 실행합니다.

Phase 1 — 요구사항 분석 커맨드

/usecase [domain-desc] [--level]

UC 명세서 작성 커맨드

도메인 설명을 Usecase 2.0 형식으로 구조화.
기본 흐름·대안 흐름·예외 흐름·비기능 요구사항 포함.
/usecase-by-example의 필수 선행 커맨드.

/usecase "주문 관리 시스템"            # 기본값: casual
/usecase "주문 관리" --level casual
/usecase "주문 관리" --level fully-dressed
/usecase-by-example [uc-file]

Gherkin 시나리오 변환 커맨드

UC명세서.md를 읽어 .feature 파일 생성.
파일 생략 시 UC명세서.md 자동 사용.
UC명세서.md 없으면 /usecase 실행을 안내하고 중단.

/usecase-by-example              # UC명세서.md 자동 읽기
/usecase-by-example order-uc.md  # 파일 지정

Phase 5 — 실행 커맨드

/run-local [--bc {bc}] [--infra-only]

로컬 실행 커맨드

arch-decisions.md를 읽어 필요한 인프라를 Docker Compose로 기동하고 Spring Boot를 시작한다.
persistence/messaging 파라미터에 따라 compose 파일을 자동 구성한다.

/run-local                  # 전체 기동 (인프라 + 앱)
/run-local --infra-only     # Docker Compose만 기동
/run-local --bc order       # 특정 BC 모듈만 기동
/run-local --profile local  # 프로파일 명시 (기본값)
사전 조건: arch-decisions.md 존재, Docker 실행 중
자동 생성: docker-compose.local.yml (없을 때)
/run-check [--verbose]

실행 상태 검증 커맨드

기동된 애플리케이션의 Run Gate 조건을 순서대로 확인한다.
실패 항목과 수정 방향을 함께 출력한다.

/run-check                  # 전체 Gate 확인
/run-check --verbose        # 상세 응답 포함 출력
검증 항목 (순서대로)
GET /actuator/health → 200 OK
② DB 커넥션 풀 정상 여부
③ BC OutputPort 구현체 주입 확인
④ messaging ≠ none → 토픽 존재 확인

Phase 3·4 — 구현 및 테스트 커맨드

/implement-bc {bc} [layer]

BC 구현 커맨드

bc-plan.md + domain-context.md + arch-decisions.md를 읽어 Wave 순서대로 구현.
arch-decisions.mdarchitecture 값(hexagonal|layered)에 따라 레이어 구조가 결정됨.
파일 없으면 즉시 중단.

/implement-bc order          # 전체
/implement-bc order domain   # 레이어 지정 (hexagonal: domain|application|adapter)
/implement-bc --wave 2       # Wave 일괄
/implement-bc --dry-run      # 실행 계획만
/implement-bc --check-plan   # 순환 의존 검사
/gen-test {bc} [scope] [flags]

테스트 생성 커맨드

Gherkin 시나리오 1:1 추적.
.feature 없으면 domain-context.md 에러 케이스 컬럼에서 도출.
arch-decisions.md의 messaging 파라미터를 읽어 계약 테스트 도구를 자동 선택.

/gen-test order              # 전체
/gen-test order application  # 레이어 지정
/gen-test order --contract   # BC 간 계약 테스트 (동기→SCC, 비동기→Pact 자동 분기)
/gen-test order --pbt        # Property-Based Testing (Jqwik, domain 레이어만)
/gen-test --e2e              # E2E 통합 시나리오
/gen-test --wave 2           # Wave 일괄
--pbt: Jqwik 불변식 탐색 --contract: SCC or Pact 자동 선택
/check-domain-version

버전 동기화 확인

domain-context.md consumers 섹션과 content-version 비교.
재생성 필요 소비자 목록과 최소 실행 순서 출력.

설계 단계 커맨드

Phase 2 커맨드

/usecase — UC 명세서 작성 (Usecase 2.0)
/usecase-by-example — UC명세서.md → .feature 변환
/ddd-modeling — domain-context.md 생성/갱신
/arch-design — arch-decisions.md 생성
/nfr-spec — NFR 도출 → arch-decisions.md ## NFR 섹션 추가
/gen-schema — Persistence → erd.mmd (Mermaid ERD) + schema.sql (DDL) 생성
/uc-to-skeleton — 스켈레톤 + PlantUML 생성

Phase 2.5 — DB 스키마 생성 커맨드

/gen-schema [--bc {bc}] [--update] [--format]

DB 스키마 생성 커맨드

arch-decisions.md ## Persistence 섹션을 읽어 Mermaid ERD(erd.mmd)와 DDL SQL(schema.sql)을 자동 생성합니다.
domain-context.md의 Aggregate → JpaEntity 매핑 규칙을 적용합니다.
persistence=jpa+jooqschema.sql을 jOOQ codegen 입력으로 사용하여 Query Side Java 클래스를 빌드 타임에 생성합니다.

/gen-schema                   # 전체 BC ERD + DDL 생성
/gen-schema --bc order        # 특정 BC만 생성
/gen-schema --update          # 변경 내용만 반영 (MAJOR/MINOR)
/gen-schema --format flyway   # Flyway V1__init.sql 형식
/gen-schema --format liquibase # Liquibase XML 형식
/gen-schema --dry-run         # 생성 계획만 출력
사전 조건
arch-decisions.md ## Persistence 섹션 존재
domain-context.md aggregates 섹션 존재
두 파일 없으면 즉시 중단 — 추론으로 스키마 생성하지 않음

Aggregate → JpaEntity 매핑 규칙

Aggregate Root → @Entity 테이블
AggregateRoot 이름 → snake_case 테이블명.
id → UUID PK.
created_at / updated_at 자동 추가.
Value Object → @Embeddable / 별도 테이블
단순 VO(Money, Address) → @Embeddable 인라인.
컬렉션 VO → 별도 테이블 + FK.
Aggregate 상태 → VARCHAR + CHECK
domain-context.md states 배열 → VARCHAR 컬럼.
CHECK (status IN ('PENDING','CONFIRMED','CANCELLED')).
BC 간 참조 → FK 금지, UUID만 저장
다른 BC Aggregate를 직접 참조하지 않음.
customer_id UUID만 저장 — JOIN 없이 ACL로 조회.
산출물
erd.mmd — Mermaid ERD (GitHub/GitLab 바로 렌더링)
schema.sql — 표준 DDL (Flyway/Liquibase + jOOQ codegen 입력)
V{n}_init_schema.sql — --format flyway 옵션 시
target/generated-sources/jooq/ — persistence=jpa+jooq 시 자동 생성

진화적 설계 — 아키텍처 마이그레이션 커맨드

/migrate-module {시나리오} [옵션]

모듈 마이그레이션 커맨드

현재 아키텍처 구조를 진화시키는 3-Gate 커맨드.
분석 리포트 → 개발자 승인 → 실행 순으로 진행하며 arch-decisions.md 업데이트와 migration-log.md 생성을 자동 처리한다.

/migrate-module single-to-multi           # single → Maven 멀티모듈
/migrate-module split-bc {bc} {bc1} {bc2} # BC 분리
/migrate-module --dry-run single-to-multi  # 분석 리포트만
/migrate-module --status                   # 진행 상태 확인
3-Gate 프로세스
Gate 1 분석 → 개발자 승인 → Gate 2 준비 → 개발자 승인 → Gate 3 실행
domain-context.md는 직접 수정하지 않음 — /ddd-modeling 재실행 권장

지원 시나리오 및 산출물

single → multi 모듈 분리
단일 패키지 → Maven 멀티모듈.
모듈 pom.xml 생성, 클래스 이동, import 경로 수정 자동화.
BC 분리 (split-bc)
1개 BC → 2개 BC.
Aggregate Root 기준 경계 제안, OutputPort 스켈레톤 자동 생성, bc-plan.md 업데이트 안내.
자동 생성 산출물
arch-decisions.md 업데이트 migration-log.md 생성 OutputPort 스켈레톤

전체 커맨드 실행 시퀀스 — 쇼핑몰 예시

# Phase 1 — 요구사항 (순차 파이프라인)
/usecase "온라인 쇼핑몰: 주문·결제·재고·알림"
# → UC명세서.md (기본값: --level casual)
# ↑ 검토·수정 후 다음 커맨드 실행

/usecase-by-example
# → UC명세서.md 자동 읽기 → *.feature 생성

# Phase 2 — 설계 (병렬 실행 후 수렴)
/ddd-modeling                 → domain-context.md  (v1.0.0)
/arch-design                  → arch-decisions.md  (consumers.arch-design: "1.0.0")
/nfr-spec                     → arch-decisions.md에 ## NFR 섹션 추가
                                  AUTO: JWT, BCrypt, MDC, Actuator, Pageable
                                  TODO: [NFR-CACHE] [NFR-CB] [NFR-RETRY]
/gen-schema                   → erd.mmd (Mermaid ERD) + schema.sql (DDL)
                                  Aggregate → JpaEntity 매핑 규칙 적용
                                  BC 간 FK 금지 — ID 참조만 허용
/uc-to-skeleton               → Java 스켈레톤 + PlantUML (NFR AUTO 클래스 포함)

# Phase 3 — 구현 (Wave 순서)
/implement-bc --wave 0        → shared 구현 (Money, Address)
/implement-bc --wave 1        → inventory 구현
/implement-bc --wave 2        → order + payment 병렬 구현 (NFR TODO 주석 삽입)
/implement-bc --wave 3        → notification 구현

# Phase 4 — 테스트
/gen-test --wave 2            → order + payment 테스트
/gen-test order --contract    → BC 간 계약 테스트 (Kafka → Pact 자동 선택)
/gen-test order --pbt         → Aggregate 불변식 Property-Based Testing
/gen-test --e2e               → 전체 E2E 시나리오

# Phase 5 — 실행
/run-local                    → Docker Compose 기동 + Spring Boot 시작
/run-check                    → Run Gate 전체 확인 (health·DB·포트·토픽)

# 도메인 모델 변경 시
/ddd-modeling                 → domain-context.md (v2.1.0, minor)
/check-domain-version         → 재생성 필요 목록 확인
/implement-bc order application  → 영향 레이어만 재실행
/gen-test order application   → 테스트 업데이트

# 진화적 설계 — 아키텍처 마이그레이션
/migrate-module --dry-run single-to-multi  → 분석 리포트 (파일 변경 없음)
/migrate-module single-to-multi            → Gate 1 분석 → 승인 → Gate 2 준비 → 승인 → Gate 3 실행
/migrate-module --status                   → 진행 중인 마이그레이션 상태 확인

# BC 분리 시나리오
/migrate-module --dry-run split-bc order order-core fulfillment
/migrate-module split-bc order order-core fulfillment
# → Gate 3 완료 후 필수 후속 작업:
/ddd-modeling                 → domain-context.md에 order-core, fulfillment BC 반영 (MAJOR)
/check-domain-version         → consumers 동기화
/implement-bc order-core application  → FulfillmentPort 호출 코드 완성
/gen-test order-core --contract       → 포트 계약 테스트 재생성