Domain Design

Language-agnostic guidance for modeling business domains. Covers the what of domain modeling — aggregates, bounded contexts, data modeling, schema evolution. Implementation skills handle the how:

• Rust skill (/rust) — newtypes, Diesel models, migrations
• TypeScript skill (/typescript) — branded types, discriminated unions
• API Design skill (/api-design) — resource design, pagination, error format

Based on Eric Evans (Domain-Driven Design), Vaughn Vernon (Implementing Domain-Driven Design, Domain-Driven Design Distilled), Martin Fowler (Patterns of Enterprise Application Architecture, refactoring.guru), and Microsoft Azure Architecture Center.

Project-specific: Check the project's CLAUDE.md for domain-specific rules covering aggregate definitions, field mappings, validation rules, and financial correctness constraints.

1. Design Philosophy

The domain model reflects business reality, not database tables or UI screens.

• Ubiquitous language — code names match domain expert vocabulary. If the business says "asset kind," the code says AssetKind, not asset_type or asset_category. Rename code to match the domain, not the other way around