PluginBench
Skill
Pass
Audit score 90

m09-domain

actionbook/rust-skills

Model domain concepts as Entities, Value Objects, and Aggregates using Rust ownership and type safety.

What is m09-domain?

Domain Modeling teaches how to translate domain-driven design (DDD) concepts into Rust patterns. Use this when designing core business types—deciding whether something is an Entity (unique identity), Value Object (interchangeable), or Aggregate (ownership hierarchy)—and enforcing invariants through type safety and private fields.

  • Distinguish Entities (unique identity) from Value Objects (interchangeable by value) and choose appropriate Rust patterns for each
  • Define Aggregate boundaries and model ownership hierarchies using Rust's ownership system
  • Enforce domain invariants through private fields, validated constructors, and type-state patterns
  • Map DDD concepts (Repository, Domain Event, Service) to Rust traits, enums, and impl blocks
  • Avoid primitive obsession by wrapping semantic types in newtypes with validation

How to install m09-domain

npx skills add https://github.com/actionbook/rust-skills --skill m09-domain
Claude Code
Cursor
Windsurf
Cline

How to use m09-domain

  1. 1.Identify the core concept you're modeling and ask: does it need unique identity or is it interchangeable by value?
  2. 2.For Entities, create a struct with an Id field and implement identity-based equality (PartialEq on id only)
  3. 3.For Value Objects, use newtypes or structs with Clone/Copy and validation in a constructor
  4. 4.Define invariants and enforce them through private fields and methods on the aggregate root
  5. 5.Use module boundaries to encapsulate aggregates and prevent direct access to internal children

Use cases

Good for
  • Designing a User entity with unique identity and Email value object with validation
  • Modeling an Order aggregate that owns OrderItems and enforces consistency rules
  • Creating a Repository trait to abstract persistence from domain logic
  • Building a domain event enum to capture state transitions (e.g., OrderCreated, OrderShipped)
  • Implementing type-safe IDs using newtypes instead of raw strings or integers
Who it's for
  • Backend engineers building domain-driven systems
  • Architects designing layered Rust applications
  • Teams establishing domain model patterns and invariants
  • Developers transitioning from DDD theory to Rust implementation

m09-domain FAQ

When should I use an Entity vs. a Value Object?

Use an Entity when two instances with different identities are considered different (e.g., User with UserId). Use a Value Object when instances are interchangeable by their attributes (e.g., Email, Money). Ask: 'Do two instances with the same data represent the same thing?'

How do I enforce domain invariants in Rust?

Make fields private, provide a validated constructor (new method returning Result), and expose only methods that maintain invariants. For example, a BankAccount should not allow negative balance—only withdrawal methods that check the invariant.

What's the difference between an Aggregate and a module?

An Aggregate is a domain concept (a cluster of entities and value objects that must be consistent). In Rust, you typically model it as a module boundary with a root struct that owns children, preventing external code from breaking invariants.

Should I use Arc or Rc for shared ownership within an Aggregate?

Prefer owned fields (parent owns children). Use Rc/Arc only if truly necessary for shared references within the aggregate. Generally, keep ownership clear and hierarchical.

How do I model a Repository in Rust?

Define a trait with methods like find(id) → Result<T>, save(entity) → Result<()>. This abstracts persistence details from domain logic, letting you swap implementations (in-memory, database, etc.).

Full instructions (SKILL.md)

Source of truth, from actionbook/rust-skills.


name: m09-domain description: "CRITICAL: Use for domain modeling. Triggers: domain model, DDD, domain-driven design, entity, value object, aggregate, repository pattern, business rules, validation, invariant, 领域模型, 领域驱动设计, 业务规则" user-invocable: false

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 ConceptRust PatternOwnership Implication
Entitystruct + IdOwned, unique identity
Value Objectstruct + Clone/CopyShareable, immutable
Aggregate Rootstruct owns childrenClear ownership tree
RepositorytraitAbstracts persistence
Domain EventenumCaptures state changes
Serviceimpl block / free fnStateless operations

Thinking Prompt

Before creating a domain type:

  1. What's the concept's identity?

    • Needs unique identity → Entity (Id field)
    • Interchangeable by value → Value Object (Clone/Copy)
  2. What invariants must hold?

    • Always valid → private fields + validated constructor
    • Transition rules → type state pattern
  3. 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 QuestionTrace ToAsk
Entity vs Value Objectdomain-*What makes two instances "the same"?
Aggregate boundariesdomain-*What must be consistent together?
Validation rulesdomain-*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 ConceptRust PatternExample
Value ObjectNewtypestruct Email(String);
EntityStruct + IDstruct User { id: UserId, ... }
AggregateModule boundarymod order { ... }
RepositoryTraittrait UserRepo { fn find(...) }
Domain EventEnumenum 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

MistakeWhy WrongBetter
Primitive obsessionNo type safetyNewtype wrappers
Public fields with invariantsInvariants violatedPrivate + accessor
Leaked aggregate internalsBroken encapsulationMethods on root
String for semantic typesNo validationValidated newtype

Related Skills

WhenSee
Type-driven implementationm05-type-driven
Ownership for aggregatesm01-ownership
Domain error handlingm13-domain-error
Specific domain rulesdomain-*