M09 Domain

This bridges domain-driven design concepts to Rust's type system and ownership model. It walks you through the entity versus value object decision, shows you how to map DDD patterns like aggregates and repositories to Rust structs and traits, and pushes you to think about invariants before writing code. The tables are dense but useful: they map domain concepts to ownership implications, which is exactly the friction point when doing DDD in Rust. Use this when you're modeling business logic and need to decide whether something should be Clone, owned, or wrapped in a newtype. The "trace up to domain constraints, trace down to implementation" structure keeps you from either over-engineering or writing anemic domain models.

skills.sh installs: 3.5K
GitHub stars: 1.6K
last updated: Aug 21, 2026

View on GitHub

Install

$ npx -y skills add actionbook/rust-skills --skill m09-domain --agent claude-code

Installs into .claude/skills of the current project.

Files

Domain Modeling

Layer 2: Design Choices

Core Question

What is this concept's role in the domain?

Before modeling in code, understand:

Is it an Entity (identity matters) or Value Object (interchangeable)?
What invariants must be maintained?
Where are the aggregate boundaries?

Domain Concept → Rust Pattern

Domain Concept	Rust Pattern	Ownership Implication
Entity	struct + Id	Owned, unique identity
Value Object	struct + Clone/Copy	Shareable, immutable
Aggregate Root	struct owns children	Clear ownership tree
Repository	trait	Abstracts persistence
Domain Event	enum	Captures state changes
Service	impl block / free fn	Stateless operations

Thinking Prompt

Before creating a domain type:

What's the concept's identity?
- Needs unique identity → Entity (Id field)
- Interchangeable by value → Value Object (Clone/Copy)
What invariants must hold?
- Always valid → private fields + validated constructor
- Transition rules → type state pattern