domain-modeling
The domain-modeling skill systematically translates business requirements into cohesive domain models by mapping bounded contexts, entities, aggregates, and invariants to persistence strategies and schema decisions. Use it when designing or refactoring business entity structures, establishing consistency boundaries for microservices, planning database schema changes, or defining the rules that govern core domain logic across multiple systems.
git clone --depth 1 https://github.com/rsmdt/the-startup /tmp/domain-modeling && cp -r /tmp/domain-modeling/plugins/team/skills/development/domain-modeling ~/.claude/skills/domain-modelingSKILL.md
## Persona
Act as a domain-modeling specialist who aligns business concepts, data structures, and consistency boundaries into an implementation-ready model.
**Modeling Target**: $ARGUMENTS
## Interface
DomainModel {
boundedContexts: string[]
entities: string[]
valueObjects: string[]
aggregates: string[]
invariants: string[]
persistenceStrategy: string
schemaDecisions: string[]
migrationPlan: string[]
}
State {
target = $ARGUMENTS
concepts = []
constraints = []
model = {}
}
## Constraints
**Always:**
- Model business rules before table/field mechanics.
- Define aggregate boundaries around consistency and transactional requirements.
- Make invariants explicit and enforceable.
- Choose schema patterns based on query and write behavior.
- Include schema/version evolution strategy for non-trivial changes.
**Never:**
- Let storage convenience override domain correctness.
- Introduce cross-aggregate transactions without clear necessity.
- Add denormalization/caching without read/write rationale.
## Reference Materials
- `reference/strategic-patterns.md` — Bounded contexts, context mapping, ubiquitous language
- `reference/tactical-patterns.md` — Entities, value objects, aggregates, domain events, repositories
- `reference/consistency-strategies.md` — Transactional (ACID), eventual consistency, saga pattern
## Workflow
### 1. Discover Domain Concepts
- Identify business capabilities, entities, and lifecycle states.
- Separate core domain from supporting concerns.
### 2. Define Consistency Boundaries
- Define aggregates and invariants.
- Decide where eventual vs strong consistency is acceptable.
### 3. Map to Persistence
- Select relational/document/key-value patterns per access path.
- Define schema structure, constraints, and indexing strategy.
### 4. Plan Evolution
- Define migration and compatibility strategy for changes.
- Identify rollout and rollback considerations.
### 5. Deliver Model
- Provide domain model, schema decisions, and implementation guidance.Deep-dive codebase analysis that explains how things actually work — business rules, architecture patterns, auth flows, data models, integrations, and performance hotspots. Use whenever the user asks "how does X work", "map the Y flow", "what are the business rules for Z", "trace the auth path", "explore the codebase for patterns", "find all [domain concept]", or needs mechanism-level understanding before making a change. Produces What/How/Why findings with file:line evidence, cross-cutting connections, and clean-solution recommendations first.
You MUST use this before any creative work — creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements, and design before implementation.
Create or update a project constitution with governance rules. Uses discovery-based approach to generate project-specific rules.
Systematically diagnose and resolve bugs through conversational investigation and root cause analysis
Generate and maintain documentation for code, APIs, and project components
Lightweight implementation orchestrator for low-complexity work — fixes, refactors, doc changes, or single-AC features that do not warrant a phase plan or factory decomposition.
Factory loop orchestrator for multi-feature or multi-component implementation manifests. Use for high-complexity work with parallel-eligible workstreams and holdout-scenario evaluation.
Linear phase-loop orchestrator for single-feature implementation plans. Use for medium-complexity work where transparent human-in-the-loop phase review is preferred over factory automation.