with one click
design-ddd
DDD 도메인 모델링 판단 기준. `/design` command의 D step에서 도메인 복잡도가 높을 때 참조.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Menu
DDD 도메인 모델링 판단 기준. `/design` command의 D step에서 도메인 복잡도가 높을 때 참조.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Library/API 설계 판단 기준. `/design` command의 D step에서 기술 라이브러리를 설계할 때 참조.
RADIO 기반 FE/BE 설계 체크리스트. `/design` command가 각 Step에서 참조하는 판단 기준과 질문 목록.
BE TechSpec 문서 작성 템플릿과 패턴. 백엔드 프로젝트의 기술 명세서를 작성할 때 참조. Use when: BE TechSpec 작성, API 설계 문서 생성, Given/When/Then 테스트 케이스 정의, DB 스키마 설계, 서비스 아키텍처 설계 문서 작성 시 사용.
Entity Object(companion object) 패턴. Entity interface와 같은 이름의 const 객체에 도메인 로직 함수를 그룹화. Use when: TDD Refactor 단계에서 반복되는 도메인 로직을 정리할 때, Entity 구현 시 도메인 로직 코드화, UI/API/테스트에서 동일 로직 재사용이 필요할 때.
FE TechSpec 문서 작성 템플릿과 패턴. Linear 프로젝트의 기술 명세서를 작성할 때 참조. Use when: TechSpec 작성, 기술 명세서 생성, Given/When/Then 테스트 케이스 정의, Acceptance Criteria 작성, Solution 설계 문서 작성 시 사용.
Seed Design React 컴포넌트 라이브러리 참고 문서. Use when: @seed-design/react 컴포넌트 사용, UI 컴포넌트 구현, seed-design 컴포넌트의 props/API 확인이 필요할 때.
| name | design-ddd |
| description | DDD 도메인 모델링 판단 기준. `/design` command의 D step에서 도메인 복잡도가 높을 때 참조. |
/design command의 D step에서 도메인이 복잡할 때 참조하는 판단 기준.
사용 방법:
/design command의 D step에서 자동 참조됨아래 중 2개 이상 해당하면 DDD 딥다이브가 필요하다:
Phase 1: 용어와 규칙을 모은다 (비즈니스 이해)
↓
Phase 2: 의미가 달라지는 경계를 긋는다 (Bounded Context)
↓
Phase 3: 경계 안에서 구체적으로 설계한다
- 함께 변해야 하는 것을 묶고 (Aggregate)
- 대표를 세우고 (Aggregate Root)
- ID가 필요한 것(Entity)과 값인 것(VO)을 구분하고
- 깨지면 안 되는 규칙을 정하고 (Invariant)
- Aggregate 간 통신 방법을 정한다 (Domain Event)
"도메인 전문가와 개발자가 같은 단어를 같은 뜻으로 쓴다"
도출 방법:
| 용어 | 정의 | 예시 |
|---|---|---|
| {명사} | {한 문장 정의} | {구체적 예} |
| {동사} | {어떤 상태를 어떻게 바꾸는가} | {구체적 예} |
검증 질문:
동음이의어 발견 시:
요구사항에서 규칙을 수집한다.
발견 방법:
"같은 단어라도 맥락에 따라 의미가 달라지는 경계"
Q: 같은 용어가 서로 다른 의미/관심사로 쓰이는 곳이 있는가?
├─ Yes → 별도 Bounded Context
└─ No → 같은 Bounded Context
예시: "상품(Product)"
같은 "상품"이지만 각 맥락에서 관심 있는 속성과 행위가 다르다.
| 관계 | 설명 | 예시 |
|---|---|---|
| 직접 설계 | 우리가 모델링하는 영역 | 쿠폰 Context |
| 외부 시스템 | ID + 최소 정보만 참조 | 주문 Context (orderId만) |
판단 질문:
"하나의 트랜잭션으로 일관성을 보장해야 하는 단위"
판단 기준:
Q: A를 변경할 때 B도 반드시 함께 변경되어야 하는가?
├─ Yes → 같은 Aggregate
└─ No → 다른 Aggregate (이벤트로 연결)
Aggregate Root:
Aggregate가 너무 클 때:
Aggregate가 너무 작을 때:
| 기준 | Entity | Value Object |
|---|---|---|
| 식별자 | 고유 ID 필요 | 값 자체로 비교 |
| 가변성 | 시간에 따라 상태 변함 | 불변 (immutable) |
| 동등성 | ID로 비교 | 모든 필드로 비교 |
| 예시 | User, Order, Coupon | Money, Address, DateRange |
결정 트리:
Q: 이 개념에 고유 식별자가 필요한가?
├─ Yes → Q: 시간에 따라 상태가 변하는가?
│ ├─ Yes → Entity
│ └─ No → 정말 ID가 필요한지 재검토
└─ No → Q: 같은 값이면 같은 것으로 취급해도 되는가?
├─ Yes → Value Object
└─ No → Entity (식별이 필요한 것)
Value Object로 만들 수 있으면 Value Object가 낫다. 이유:
"Aggregate가 항상 보장해야 하는 조건"
형식: {Aggregate}의 {조건}은 항상 {보장}이어야 한다
발견 방법:
검증:
"정보 전문가 원칙: 그 판단에 필요한 정보를 누가 갖고 있는가?"
판단 흐름:
Q: 이 행위에 필요한 정보를 누가 갖고 있는가?
├─ 단일 Entity/VO가 가짐 → 그 Entity/VO의 메서드
├─ Aggregate Root가 관리 → Aggregate Root의 메서드
├─ 여러 Aggregate에 걸침 → Domain Service
└─ 외부 시스템 정보 필요 → Application Service (Port를 통해)
"Aggregate 간 비동기 통신 수단"
필요한 경우:
이벤트 설계 기준:
| 실수 | 문제 | 해결 |
|---|---|---|
| Phase 2 건너뛰기 | 경계 없이 모든 것이 한 덩어리 | 동음이의어가 있으면 Context 분리 |
| 모든 것을 Entity로 | VO가 적합한 것까지 ID 부여 | "정말 ID가 필요한가?" |
| Aggregate가 하나 | God Object | 변경 빈도와 생명주기로 분리 |
| 불변식 누락 | 비즈니스 규칙 위반 허용 | 규칙마다 "누가 보장?" 질문 |
| Domain Event에 너무 많은 정보 | 결합도 증가 | 수신자 기준 최소 정보 |
| 외부 의존을 Domain에 | Dependency Rule 위반 | Port interface로 역전 |