Guides domain modeling in Rust using DDD concepts such as entities, value objects, and aggregates.
- What it does
- This skill provides design guidance for translating domain concepts into Rust patterns, mapping entities, value objects, aggregate roots, repositories, domain events, and services to concrete Rust constructs. It offers thinking prompts about identity, invariants, and ownership, plus pattern templates for value objects, entities, and aggregates. It also lists common modeling mistakes and points to related skills for type-driven design, ownership, and domain error handling.
- When to use it
- Use it when modeling a business domain in Rust and deciding whether a concept is an entity or value object, where aggregate boundaries lie, or how to enforce invariants. It is also useful when reviewing a domain model for primitive obsession, leaked internals, or unclear ownership.
- Requirements
- No scripts or special tooling; it is an instructions-only reference. The examples assume Rust and familiarity with DDD terminology.
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
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
-
Who owns this data?
- Single owner (parent) → owned field
- Shared reference → Arc/Rc
- Weak reference → Weak
Trace Up ↑
To domain constraints (Layer 3):
Trace Down ↓
To implementation (Layer 1):
Quick Reference
Pattern Templates
Value Object
Entity
Aggregate
Common Mistakes
Related Skills