sdlc-domain-boundary-modeling

name	sdlc-domain-boundary-modeling
description	Use to model bounded contexts, capabilities, ownership, domain data/language, allowed interactions, and forbidden dependencies.
metadata	{"version":"0.5","updated":"2026-07-23"}

Domain Boundary Modeling

Use this skill to model business-domain boundaries for a modular system.

In the lightweight SDLC-ADS model, durable domain knowledge should usually land in local/sdlc/领域.md as ownership, data, allowed dependency, forbidden dependency, glossary, or open-question updates. A standalone Domain Boundary Map is still valid for larger work, but small direct-dev tasks should not be forced into full DDD artifacts.

Use when

• The system has multiple business capabilities.
• Modules should be organized by domain rather than only technical layers.
• There is risk of business rules spreading across unrelated modules.
• The user asks for DDD, bounded contexts, domain model, domain boundary map, or module ownership.

Inputs

• BRD/URS/PRD/SRS.
• Existing project capability map.
• Current modules, routes, APIs, schemas, and terminology.
• Business workflows, roles, states, and rules.
• Git history and co-change evidence when available and relevant to a disputed boundary.
• Existing local/sdlc/_资产.md, local/sdlc/架构.md, local/sdlc/领域.md, and current 00-状态.md when present.

Workflow

1. Extract business capabilities.
2. Identify candidate domains and bounded contexts using business capability, data ownership and invariants, shared language, ownership, and reasons to change.
3. Use co-change only as corroborating evidence for a candidate seam; do not let repository history alone decide a bounded context.
4. Define each domain's responsibility.
5. Define data ownership and the invariants each owner protects.
6. Define exposed interfaces.
7. Define allowed dependencies and forbidden access.
8. Build a shared domain glossary.
9. Identify ambiguous concepts that need owner decisions.
10. Decide whether the output is a standalone boundary map, an incremental 领域.md update, or both.

Validation

Check:

• Each domain has one clear business responsibility.
• Data ownership is not duplicated without reason.
• Cross-domain calls are explicit.
• An ordinary business change does not require edits across unrelated domains.
• Cross-domain data and semantic dependencies are explicit, including the owner of shared terms and invariants.
• Shared concepts are named consistently.
• Forbidden dependencies are documented.
• The model supports modular monolith first unless microservices are justified.

Output

Return:

1. Domain boundary map
2. Bounded context list
3. Data ownership map
4. Allowed dependency map
5. Forbidden dependency list
6. Domain glossary
7. Module naming proposal
8. Open questions

For lightweight ADS state, return or update:

# 领域

## 能力归属
- DOM-001：

## 数据归属
- DOM-002：

## 允许依赖
- DOM-003：

## 禁止依赖
- DOM-004：

## 术语
-

## 推断 / 未确认
- Q-001：

Boundaries

• Do not implement code.
• Do not force DDD patterns into a simple script or small local task.
• Do not create microservices merely because domains exist.
• Do not require full DDD artifacts for direct-dev tasks.
• Do not duplicate durable domain constraints in per-delivery specs when they should live in local/sdlc/领域.md.

Handoff

Use sdlc-modular-monolith-architecture to map domains into repository structure, sdlc-hld-workflow for architecture, and sdlc-dev-handoff-planning for tasks.

Dev fallback: Dev can use SDLC / ADD / DDD / SDD materials when they exist, but dev can also continue without them when the task is clear, bounded, and testable from user request, issue, bug report, failing test, local diff, or repository evidence. Missing artifacts are risk/context, not automatic refusal.