From studio-insight
Create a domain canvas that maps business domains, their classifications (core/supporting/generic), boundaries, and relationships. Use when you need to understand system architecture, draw service boundaries, decide what to build vs buy, or when someone asks "how should we structure this". Produces a structured domain model document.
How this skill is triggered — by the user, by Claude, or both
Slash command
/studio-insight:domain-canvasThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Produce a domain canvas — a visual map of business domains, their roles, boundaries, and interactions. Helps decide what deserves a custom plugin (core), what's supporting, and what can use off-the-shelf tools.
Produce a domain canvas — a visual map of business domains, their roles, boundaries, and interactions. Helps decide what deserves a custom plugin (core), what's supporting, and what can use off-the-shelf tools.
This skill uses dynamic expert loading. On every run:
architect.md (leads domain analysis)studio/agents/*.md — load all custom experts the team has created${CLAUDE_SKILL_DIR}/../../agents/*.md — load shipped experts (skip any already loaded from project)## Your Domain section and title against the user's input topic. Include 1-3 most relevant domain experts._domain-expert-template.md — it's for creating new experts, not for consultation.The primary role produces the initial artifact. Domain experts review and correct it in the Expert Review step.
Accept one of:
$ARGUMENTS (e.g., "儿童健康管理平台")event-storm.md for events and personas/ for actorsIdentify distinct business areas by clustering:
Use the language test: if practitioners use different vocabulary, it's probably a different domain.
Name each domain in plain business language (2-3 words):
For each domain, specify:
┌─────────────────────────────────────┐
│ {Domain Name} │
├─────────────────────────────────────┤
│ Owns: │
│ - {data entities} │
│ - {business rules} │
│ - {user-facing capabilities} │
│ │
│ Does NOT own: │
│ - {explicit exclusions} │
│ - {things that belong elsewhere} │
│ │
│ Key actors: │
│ - {who interacts with this domain} │
│ │
│ Key events: │
│ - {events this domain produces} │
│ - {events this domain consumes} │
└─────────────────────────────────────┘
The boundary test: "If I removed this domain entirely, would the others still make sense?"
Assess each domain:
┌───────────────────────────────────────────────────────────┐
│ Domain Classification │
├──────────────┬──────────┬─────────────────────────────────┤
│ Domain │ Type │ Rationale │
├──────────────┼──────────┼─────────────────────────────────┤
│ 营养管理 │ Core │ 核心差异化,用户选择产品的原因 │
│ 运动追踪 │ Support │ 重要辅助,但不是主打 │
│ 用户档案 │ Generic │ 标准 CRUD,内置工具可满足 │
│ 健康报告 │ Support │ 有价值但依赖其他域数据 │
└──────────────┴──────────┴─────────────────────────────────┘
| Type | Meaning | Build strategy |
|---|---|---|
| Core | Unique value, competitive advantage | Custom plugin, invest in quality |
| Supporting | Necessary but not differentiating | Add-on plugin, adequate quality |
| Generic | Standard capability | Use existing tools (MCP, built-in) |
Define how domains interact:
| Relationship | Symbol | Meaning |
|---|---|---|
| Feeds into | ──▶ | A produces data that B consumes |
| Shares data | ◀──▶ | Both read/write same entities |
| Independent | · · · | No interaction |
| Orchestrates | ══▶ | A coordinates B's behavior |
Produce the domain canvas as a visual map:
┌──────────────────────────────────────────────────┐
│ Domain Canvas │
│ {Project Name} │
├──────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ 营养管理 ★ │──▶──▶──│ 健康报告 │ │
│ │ [Core] │ │ [Supporting] │ │
│ └──────┬───────┘ └──────▲───────┘ │
│ │ │ │
│ │ shares │ feeds │
│ ▼ │ │
│ ┌──────────────┐ │ │
│ │ 用户档案 │ │ │
│ │ [Generic] │ │ │
│ └──────┬───────┘ │ │
│ │ │ │
│ │ feeds │ │
│ ▼ │ │
│ ┌──────────────┐ │ │
│ │ 运动追踪 │──▶──▶────────┘ │
│ │ [Supporting] │ │
│ └──────────────┘ │
│ │
│ ★ = Core domain │
│ [Generic] domains → use existing tools │
└──────────────────────────────────────────────────┘
If domain experts were discovered in Expert Discovery, use the Agent tool to have each relevant expert review the domain canvas.
Give each expert subagent:
Incorporate corrections. Common improvements from domain experts:
If no relevant domain experts were found, skip this step.
Present the canvas to the user:
If working within a studio workspace:
studio/changes/{domain}/domain-canvas.md
If standalone, write to the current directory.
The file contains:
npx claudepluginhub ameng2001/astra-studio-plugins --plugin studio-insightModels bounded contexts, capabilities, ownership, domain data/language, allowed interactions, and forbidden dependencies for modular systems.
Designs DDD strategic artifacts including subdomains, bounded contexts, and ubiquitous language for complex business domains. Useful for classifying subdomains, splitting monoliths, and aligning teams.
Designs DDD strategic artifacts: subdomain classification, bounded contexts, and ubiquitous language for complex business domains.