Verify code against domain policies, state machines, and event flows. Checks terminology consistency, forbidden state transitions, policy compliance, and event flow ordering. Use when: doing code review, PR review, implementing new business logic, after modifying domain code, or when anyone asks to 'check domain rules', 'verify policies', 'review domain compliance', 'validate business rules', 'check state transitions', or says things like 'does this code follow our domain rules' or 'is this refund logic correct'. Also trigger on 'domain check', 'policy check', 'domain validation', or when reviewing code in order/, coupon/, payment/ directories.
구현된 코드가 docs/domain/의 도메인 규칙과 일치하는지 자동 검증한다.
사람이 매번 확인하지 않아도, Claude가 PR 리뷰 시 도메인 정책 위반을 탐지한다.
이 에이전트는 4가지를 검증한다:
# Option A: Changed files (PR review)
git diff --name-only HEAD~1
# Option B: User-specified files
# (use files provided by user)
# Option C: Full domain scan
find src/main/ -name "*.java" \( -path "*/domain/*" -o -path "*/service/*" \)
파일 경로에서 도메인을 추출한다:
*/order/* → order domain*/coupon/* → coupon domain*/payment/* → payment domain*/service/OrderService* → order domainglossary.md의 혼동 쌍(Confused Pairs) 섹션을 로드하고:
For each confused pair (A vs B):
1. A가 B의 맥락에서 사용되고 있지 않은가?
예: "cancel" 메서드가 결제 후(COMPLETED) 로직에서 호출
2. 코드의 클래스/메서드명이 용어사전과 일치하는가?
예: "refund" 로직인데 메서드명이 "cancelPayment"
3. 주석이나 로그 메시지에서 잘못된 용어가 쓰이고 있지 않은가?
정책 문서의 각 POLICY-xxx에 대해:
For each POLICY-{ID}:
1. 이 정책이 코드에 구현되어 있는가?
- if/throw 패턴으로 검증 로직이 존재하는가
- validation 메서드가 호출되고 있는가
2. 정책의 "예외" 케이스가 처리되어 있는가?
예: POLICY-REFUND-002 (VIP 14일 연장) → VIP 분기 로직 존재?
3. 정책의 수치가 코드와 일치하는가?
예: "7일" → Duration.ofDays(7) 또는 관련 상수
상태 다이어그램의 금지된 전이 테이블에 대해:
For each forbidden transition (FROM → TO):
1. 코드에서 이 전이가 가능한 경로가 있는가?
- Entity의 상태 변경 메서드에서 FROM 상태 체크 누락
- Service에서 상태 확인 없이 직접 상태 변경
2. 상태 변경 시 적절한 검증이 있는가?
- if (status != EXPECTED) throw ...
이벤트 흐름 문서와 코드의 호출 순서 비교:
For each flow:
1. 코드의 메서드 호출 순서가 이벤트 흐름과 일치하는가?
2. 실패 보상 처리가 구현되어 있는가?
- catch 블록에서 보상 로직 존재?
- 보상 순서가 역순인가?
3. 비동기 경계가 올바른가?
- @Async로 표시된 메서드가 실제로 비동기인가?
Report all findings using these categories:
- POLICY-COUPON-001: 쿠폰 중복 사용 검증 — 준수
위치: CouponService.java:48
- POLICY-ORDER-003: 30분 자동 취소 배치 누락
위치: OrderService.java (배치 스케줄러 미존재)
영향: PENDING 상태 주문이 영구 방치될 수 있음
수정 제안: @Scheduled로 자동 취소 로직 추가
- 금지된 전이 DELIVERED → CANCELLED 가능 경로 발견
위치: OrderService.java:82 cancelOrder()
원인: DELIVERED 상태 체크 없이 cancel() 호출
수정 제안: DELIVERED 상태는 requestRefund()로 처리
- "cancel" 메서드가 결제 후 로직에서 사용됨
위치: OrderService.java:80 cancelOrder()
올바른 용어: 결제 완료 후이므로 "refund"
수정 제안: 메서드명을 requestRefund()로 변경하거나 분리
- payment 도메인의 retry 정책이 docs/domain/policies/에 정의되지 않음
코드에는 MAX_RETRY=3이 하드코딩되어 있으나 정책 문서 없음
검증 결과 요약:
## 검증 요약
- 검증 대상: N개 파일
- ✅ 준수: N건
- ❌ 정책 위반: N건
- ⚠️ 상태 전이 위반: N건
- ⚠️ 용어 혼동: N건
- ❓ 정책 미정의: N건