使い方
- インストールコマンドをコピーし、自分の環境へ導入する前にソースを確認します。
- 必要なツール、認証情報、対応環境を原文で確認します。
- 入力と成果物を指定し、出力を資料と照合します。
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).
