m09-domain▌
zhanghandong/rust-skills · updated Apr 8, 2026
Domain-driven design patterns for modeling entities, value objects, and aggregates in Rust.
- ›Distinguishes between Entities (unique identity required), Value Objects (interchangeable by value), and Aggregates (owned hierarchies), with clear Rust patterns for each
- ›Emphasizes invariant preservation through private fields, validated constructors, and type-state patterns
- ›Provides templates for common DDD structures: newtypes for value objects, structs with ID fields for entities, and modu
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
-
Who owns this data?
- Single owner (parent) → owned field
- Shared reference → Arc/Rc
- Weak reference → Weak
Trace Up ↑
To domain constraints (Layer 3):
"How should I model a Transaction?"
↑ Ask: What domain rules govern transactions?
↑ Check: domain-fintech (audit, precision requirements)
↑ Check: Business stakeholders (what invariants?)
| Design Question | Trace To | Ask |
|---|---|---|
| Entity vs Value Object | domain-* | What makes two instances "the same"? |
| Aggregate boundaries | domain-* | What must be consistent together? |
| Validation rules | domain-* | What business rules apply? |
Trace Down ↓
To implementation (Layer 1):
"Model as Entity"
↓ m01-ownership: Owned, unique
↓ m05-type-driven: Newtype for Id
"Model as Value Object"
↓ m01-ownership: Clone/Copy OK
↓ m05-type-driven: Validate at construction
"Model as Aggregate"
↓ m01-ownership: Parent owns children
↓ m02-resource: Consider Rc for shared within aggregate
Quick Reference
| DDD Concept | Rust Pattern | Example |
|---|---|---|
| Value Object | Newtype | struct Email(String); |
| Entity | Struct + ID | struct User { id: UserId, ... } |
| Aggregate | Module boundary | mod order { ... } |
| Repository | Trait | trait UserRepo { fn find(...) } |
| Domain Event | Enum | enum OrderEvent { Created, ... } |
Pattern Templates
Value Object
struct Email(String);
impl Email {
pub fn new(s: &str) -> Result<Self, ValidationError> {
validate_email(s)?;
Ok(Self(s.to_string()))
}
}
Entity
struct UserId(Uuid);
struct User {
id: UserId,
email: Email,
// ... other fields
}
impl PartialEq for User {
fn eq(&self, other: &Self) -> bool {
self.id == other.id // Identity equality
}
}
Aggregate
mod order {
pub struct Order {
id: OrderId,
items: Vec<OrderItem>, // Owned children
// ...
}
impl Order {
pub fn add_item(&mut self, item: OrderItem) {
// Enforce aggregate invariants
}
}
}
Common Mistakes
| Mistake | Why Wrong | Better |
|---|---|---|
| Primitive obsession | No type safety | Newtype wrappers |
| Public fields with invariants | Invariants violated | Private + accessor |
| Leaked aggregate internals | Broken encapsulation | Methods on root |
| String for semantic types | No validation | Validated newtype |
Related Skills
| When | See |
|---|---|
| Type-driven implementation | m05-type-driven |
| Ownership for aggregates | m01-ownership |
| Domain error handling | m13-domain-error |
| Specific domain rules | domain-* |
Discussion
Product Hunt–style comments (not star reviews)- No comments yet — start the thread.
Ratings
4.6★★★★★36 reviews- ★★★★★Evelyn Martinez· Dec 24, 2024
We added m09-domain from the explainx registry; install was straightforward and the SKILL.md answered most questions upfront.
- ★★★★★Amina Taylor· Dec 16, 2024
m09-domain fits our agent workflows well — practical, well scoped, and easy to wire into existing repos.
- ★★★★★Noah Yang· Nov 15, 2024
m09-domain reduced setup friction for our internal harness; good balance of opinion and flexibility.
- ★★★★★Mateo Kapoor· Nov 7, 2024
Registry listing for m09-domain matched our evaluation — installs cleanly and behaves as described in the markdown.
- ★★★★★Aditi Taylor· Oct 26, 2024
m09-domain reduced setup friction for our internal harness; good balance of opinion and flexibility.
- ★★★★★Olivia Liu· Oct 6, 2024
Registry listing for m09-domain matched our evaluation — installs cleanly and behaves as described in the markdown.
- ★★★★★Piyush G· Sep 25, 2024
m09-domain has been reliable in day-to-day use. Documentation quality is above average for community skills.
- ★★★★★Olivia Nasser· Sep 21, 2024
m09-domain reduced setup friction for our internal harness; good balance of opinion and flexibility.
- ★★★★★Oshnikdeep· Sep 17, 2024
I recommend m09-domain for anyone iterating fast on agent tooling; clear intent and a small, reviewable surface area.
- ★★★★★Yuki Sethi· Sep 17, 2024
Solid pick for teams standardizing on skills: m09-domain is focused, and the summary matches what you get after install.
showing 1-10 of 36