사용 방법
- 설치 명령을 복사하고 자신의 에이전트 환경에 설치하기 전에 소스 패키지를 확인하세요.
- 필요한 도구, 인증 정보, 지원 환경은 원본 문서에서 확인하세요.
- 입력과 원하는 산출물을 설명하고 출처와 결과를 대조하세요.
npx skills add https://github.com/yonatankarp/software-design-skills --skill ddd-bounded-context시작 전 확인
- 설치에는 모델 구독, API 한도, 파일 접근 권한이 포함되지 않습니다.
- 별점 수와 설치 수는 활동 지표이며 독립적인 품질·보안 검증이 아닙니다.
원본 저장소의 제목, 예시, 코드, 표, 링크, 이미지를 유지해 표시합니다.
One-line summary
A bounded context is the explicit boundary within which a single model — and the ubiquitous language that names it — is consistent and complete.
When to use this skill
- The same noun means two different things in different parts of the system ("customer" in sales vs "customer" in support).
- A model is growing tangled and individual changes ripple in unexpected directions.
- Team boundaries don't match code boundaries.
- The team is debating "should this be its own service?".
When NOT to use this skill
- Within-context refactoring — delegate to tactical pattern skills.
- Questions about how contexts relate to each other → route to
ddd-context-mapping. - Allocating modeling effort across the business → route to
ddd-subdomain-classification.
Core content
A bounded context is conceptual, not deployment-bound. It is the scope within which a model holds together. It can be a module, a package, a microservice, or a whole system — what matters is that inside the boundary, every term has one meaning and every rule is consistent.
Signals that a boundary is needed.
- The same word means two different things in two different parts of the system.
- Two rules of the model contradict each other depending on which area of code is running.
- Two teams keep stepping on each other's changes to "the same" model.
- The UI for one user group looks nothing like the UI for another, but they hit the same domain code.
Context vs microservice. A bounded context is a model boundary; a microservice is a deployment boundary. They often coincide but don't have to. A single service can host two contexts (kept clean by module boundaries). Two services can implement the same context (rare, usually a mistake).
Naming the boundary. Give each context a name that reflects its business purpose: Sales, Billing, Shipping, Identity. Avoid technical names (Backend, Core). The name should make sense to a domain expert.
Decision heuristics
- Prefer fewer, larger contexts at the start of a project. Splitting is cheap; merging is expensive.
- Split when terms collide irreconcilably, when teams need autonomy, or when the model rules contradict.
- Do not assume one bounded context per microservice. The mapping is decided by the model, not the deployment topology.
Anti-patterns
- Declaring a bounded context per database table — performative, no model boundary actually drawn.
- Ignoring boundaries until the model breaks — by which point the cleanup is a major project.
- Treating "bounded context" as a synonym for "microservice".
- Drawing a boundary without naming the ubiquitous language inside it.
See also
ddd-ubiquitous-language— what lives inside the boundary.ddd-context-mapping— how contexts relate to each other.ddd-subdomain-classification— which contexts deserve the most effort.
References
- Evans, Domain-Driven Design (2003), Ch. 14 (Maintaining Model Integrity).
