一键导入
design-ddd
DDD 도메인 모델링 판단 기준. `/design` command의 D step에서 도메인 복잡도가 높을 때 참조.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
DDD 도메인 모델링 판단 기준. `/design` command의 D step에서 도메인 복잡도가 높을 때 참조.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| 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로 역전 |
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 확인이 필요할 때.