A-ADM Core 방법론의 Claude Code + Java 21 구현 어댑터.
Spring Boot 3.x · 헥사고날 아키텍처 · 12개 슬래시 커맨드로 SDLC 전 단계를 자동화합니다.
A-JADM은 A-ADM Core의 Claude Code 구현 어댑터입니다.
Java 21 + Spring Boot + 아키텍처 (헥사고널 | 레이어드) 스택으로,
SKILL.md 7개와 슬래시 커맨드 12개로 SDLC 전 단계를 자동화합니다.
이 문서는 A-ADM Core의 Claude Code + Java 21 구현 어댑터입니다.
설계 원칙 · 계약 파일 스키마 · 추적성 규칙 · Wave 토폴로지 등 방법론 본질은 Core 문서를 참조하세요.
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
openapi.yaml 초안을 기반으로 프론트엔드 파이프라인을 병렬로 진행할 수 있습니다.
A-ADM의 핵심 패러다임 전환과 계약 파일이 필요한 이유는 A-ADM Core 문서에 상세히 설명되어 있습니다.
이 섹션에서는 Claude Code 환경에서의 실제 적용 포인트를 정리합니다.
각 스킬은 SKILL.md 파일 하나로 완결됩니다. Claude Code가 파일을 읽고 실행 — 세션마다 프롬프트 재작성 불필요.
domain-context.md가 없으면 스킬이 즉시 중단합니다. 계약 없는 추론 실행은 허용되지 않습니다.
CLAUDE.md에 정의된 12개 커맨드로 SDLC 전 단계를 한 줄로 실행. BC 단위 점진적 구현이 기본 전략입니다.
5대 원칙의 전체 정의는 A-ADM Core → 설계 원칙을 참조하세요.
Claude Code 어댑터 관점에서의 적용 방식을 정리합니다.
company, domain, base-package, java-version만 바꾸면 새 프로젝트에 즉시 적용됩니다.
gen-test 스킬이 시나리오 ID 주석과 1:1 @Test를 자동 생성합니다.
arch-decisions.md 없이 /implement-bc를 실행하면 즉시 에러. 추론 모드 폴백 없음.
usecase-by-example ∥ ddd-modeling 수렴 후 bc-plan.md Wave 순서로 구현.
요구사항 분석부터 실행까지, 각 단계는 명확한 입력·산출물·게이트를 가집니다.
| --level | 분량 | 용도 |
|---|---|---|
| brief | 2~5줄 | 파이프라인 사용 금지 |
| casual | ~1페이지 | 기본값 — 내부 팀용 |
| fully-dressed | 3~5페이지 | 외부 이해관계자·복잡 예외 |
| UC 명세서 항목 | Gherkin 변환 |
|---|---|
| 사전조건 | Given |
| 기본 흐름 행위 (액터) | When |
| 기본 흐름 응답 (시스템) | Then |
| 대안 흐름 | Scenario 추가 |
| 예외 흐름 | 에러 케이스 Scenario |
/gen-test --pbt
@Property — 불변식 위반 경계값 자동 탐색@ForAll @Positive — 수치 범위 제약 자동 적용Arbitrary<T> — 복합 도메인 객체 생성기/gen-test --contract
arch-decisions.md의 messaging 파라미터를 읽어 도구를 자동 선택.--profile local 자동 적용.local — Docker Compose 인프라, 디버그 로그. test — Testcontainers 자동 기동, 격리 DB. prod — 외부 인프라 연결, 최소 로그.| 프로파일 | DB | Kafka | 기동 방법 |
|---|---|---|---|
| local | Docker | Docker | docker compose up |
| test | TC | TC | mvn verify 시 자동 |
| prod | 외부 | 외부 | 환경 변수 주입 |
GET /actuator/health → 200 OKservices:
postgres:
image: postgres:16-alpine
ports: ["5432:5432"]
environment:
POSTGRES_DB: appdb
services:
kafka:
image: bitnami/kafka:3.7
ports: ["9092:9092"]
environment:
KAFKA_CFG_NODE_ID: 0
spring:
profiles:
active: local
datasource:
url: jdbc:postgresql://
localhost:5432/appdb
/gen-schema 산출물(schema.sql)을 jOOQ codegen이 읽어 Java 클래스 자동 생성.pom.xml에 jOOQ codegen 플러그인 추가 필요 (arch-decisions.md 기반 자동 구성).
각 스킬은 프로젝트 루트의 .claude/skills/ 디렉토리에 SKILL.md 파일로 저장됩니다.
슬래시 커맨드 실행 시 Claude Code가 해당 파일을 읽고 계약 파일을 참조하여 산출물을 생성합니다.
세션 간 상태 유지는 계약 파일이 담당하므로 스킬 자체는 무상태(stateless)입니다.
각 스킬은 독립적인 SKILL.md 오케스트레이터 + 참조 파일로 구성됩니다.
Phase 1은 순차 파이프라인, Phase 2 이후는 계약 파일로만 소통합니다.
도메인 설명을 Usecase 2.0 형식의 구조화된 명세서로 작성.
수준(--level)에 따라 Brief / Casual / Fully-dressed 산출.
brief는 파이프라인 사용 금지 — Gherkin 변환에 정보 부족--level casual
UC명세서.md를 읽어 Gherkin .feature 파일로 변환.
ddd-modeling과 병렬 실행 후 수렴 체크.
Step 1 BC 식별 → Step 2 Aggregate 설계 → Step 3 Command/Event 매핑 → Step 4 UL 사전 + 수렴 검증.
Step 1 모듈 구조 → Step 2 BC 간 통신 → Step 3 어댑터 구조 → Step 4 공유 커널 위치.
Lombok 금지 규칙 포함.
architecture: hexagonal | layered — 레이어 구조 결정module: single | multi — Maven 모듈 분리 여부persistence: jpa | jpa+jooq | jdbc — jpa+jooq = Command(JPA) + Query(jOOQ) CQRS
성능·보안·가용성·운영성 4개 카테고리를 대화로 도출하고 arch-decisions.md의 ## NFR 섹션을 채운다.
코드 생성 지시를 AUTO(자동 생성)와 TODO(태그 주석)로 분류.
두 계약 파일을 입력으로 클래스/패키지 스켈레톤과 PlantUML 시퀀스 다이어그램 생성.
NFR AUTO 항목 클래스 포함. 추론 없는 1:1 매핑.
스킬 간 인터페이스를 파일로 명문화합니다.
소비자 커맨드는 파일 없이는 추론 모드로 실행하지 않습니다.
도메인 설명 (자연어)
↓
/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 추적)
여러 Bounded Context를 가진 프로젝트의 구현 순서, BC 간 통신, 공유 커널을 체계적으로 관리합니다.
즉각 응답이 필요한 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 { ... }
결과적 일관성으로 충분한 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) { ... }
/check-domain-version 커맨드 동작을 설명합니다.
도메인 모델 변경이 어떤 산출물에 영향을 주는지 정확히 추적합니다.
불필요한 전체 재생성을 방지합니다.
## 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-type | arch-design | uc-to-skeleton | implement-bc | gen-test |
|---|---|---|---|---|---|
| BC 추가/삭제 | major | 전면 재실행 | 전체 BC | bc-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만 |
슬래시 커맨드는 A-ADM Core의 5단계 워크플로를 Claude Code 환경에서 실행하는 진입점입니다.
CLAUDE.md에 정의하며, 다른 AI 도구 어댑터에서는 동등한 트리거 메커니즘으로 대체합니다.
CLAUDE.md에 정의된 커맨드가 전 단계를 자동화합니다.
모든 커맨드는 계약 파일을 읽어 추론 없이 실행합니다.
도메인 설명을 Usecase 2.0 형식으로 구조화.
기본 흐름·대안 흐름·예외 흐름·비기능 요구사항 포함.
/usecase-by-example의 필수 선행 커맨드.
/usecase "주문 관리 시스템" # 기본값: casual /usecase "주문 관리" --level casual /usecase "주문 관리" --level fully-dressed
UC명세서.md를 읽어 .feature 파일 생성.
파일 생략 시 UC명세서.md 자동 사용.
UC명세서.md 없으면 /usecase 실행을 안내하고 중단.
/usecase-by-example # UC명세서.md 자동 읽기 /usecase-by-example order-uc.md # 파일 지정
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 # 프로파일 명시 (기본값)
기동된 애플리케이션의 Run Gate 조건을 순서대로 확인한다.
실패 항목과 수정 방향을 함께 출력한다.
/run-check # 전체 Gate 확인 /run-check --verbose # 상세 응답 포함 출력
GET /actuator/health → 200 OKbc-plan.md + domain-context.md + arch-decisions.md를 읽어 Wave 순서대로 구현.
arch-decisions.md의 architecture 값(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 # 순환 의존 검사
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 일괄
domain-context.md consumers 섹션과 content-version 비교.
재생성 필요 소비자 목록과 최소 실행 순서 출력.
/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 생성arch-decisions.md ## Persistence 섹션을 읽어 Mermaid ERD(erd.mmd)와 DDL SQL(schema.sql)을 자동 생성합니다.
domain-context.md의 Aggregate → JpaEntity 매핑 규칙을 적용합니다.
persistence=jpa+jooq 시 schema.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 섹션 존재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 시 자동 생성
현재 아키텍처 구조를 진화시키는 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 # 진행 상태 확인
domain-context.md는 직접 수정하지 않음 — /ddd-modeling 재실행 권장
# 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 → 포트 계약 테스트 재생성