Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
zhanghandong avatar

M09 Domain

  • 762 installs
  • 1.3k repo stars
  • Updated May 24, 2026
  • zhanghandong/rust-skills

This is a copy of m09-domain by actionbook - installs and ranking accrue to the original listing.

m09-domain is a Rust domain-modeling skill that maps business concepts to Entity, Value Object, Aggregate, and Repository patterns with ownership rules for developers practicing domain-driven design before coding.

About

m09-domain is a Layer 2 design skill from zhanghandong/rust-skills that answers whether a concept is an Entity or Value Object, which invariants must hold, and where aggregate boundaries belong in Rust. It triggers on domain model, DDD, entity, value object, aggregate, repository pattern, business rules, validation, and invariant keywords in English and Chinese. The skill pairs domain concepts with Rust patterns and ownership implications in a reference table before implementation. Backend Rust developers use m09-domain when translating business rules into types, validation, and repository interfaces instead of jumping straight to structs and SQL.

  • Maps 6 core DDD concepts (Entity, Value Object, Aggregate Root, Repository, Domain Event, Service) to Rust ownership pat
  • 3-step thinking prompt that forces identity, invariant, and ownership decisions before coding
  • Prevents common Rust modeling mistakes by clarifying when to use struct + Id versus Clone/Copy
  • Includes type-state pattern guidance for enforcing business rules and invariants at compile time
  • Hard-gate: run before any domain type is created in code

M09 Domain by the numbers

  • 762 all-time installs (skills.sh)
  • +6 installs in the week ending Jul 28, 2026 (Skillselion tracking)
  • Security screen: MEDIUM risk (skills.sh audit)
  • Data as of Jul 28, 2026 (Skillselion catalog sync)
npx skills add https://github.com/zhanghandong/rust-skills --skill m09-domain

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs762
repo stars1.3k
Security audit3 / 3 scanners passed
Last updatedMay 24, 2026
Repositoryzhanghandong/rust-skills

How do you model DDD entities and aggregates in Rust?

Translate business concepts into correct Rust domain models using Entity, Value Object, Aggregate and Repository patterns before writing implementation code.

Who is it for?

Rust backend developers practicing DDD who need entity versus value object decisions, invariants, and repository boundaries before writing code.

Skip if: Quick CRUD scaffolding without business rules or projects that do not need explicit aggregate or invariant modeling.

When should I use this skill?

The user mentions domain model, DDD, entity, value object, aggregate, repository pattern, business rules, validation, or invariants in Rust.

What you get

Rust domain type map, aggregate boundary diagram, invariant list, and repository interface sketches.

  • Domain type classification
  • Aggregate boundary map
  • Repository interface sketch

Files

SKILL.mdMarkdownGitHub ↗

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-*

Related skills

How it compares

Use m09-domain for upfront DDD modeling; use implementation-focused Rust skills once types, invariants, and repositories are already defined.

FAQ

What question does m09-domain answer first?

m09-domain starts by asking what role a concept plays in the domain—whether it is an Entity with identity, a Value Object, which invariants apply, and where aggregate boundaries should be drawn in Rust.

Which Rust patterns does m09-domain cover?

m09-domain covers Entity, Value Object, Aggregate, and Repository patterns with ownership implications, pairing each domain concept with the correct Rust type structure before coding.

Is M09 Domain safe to install?

skills.sh reports 3 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.

Backend & APIsbackendintegrations

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.