m09-domain

Model DDD domain concepts with Rust patterns for entities and value objects.

1|2|Updated Oct 10, 2025
One-click install
npx skills add https://github.com/dojoengine/torii-core --skill m09-domain-dojoengine
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: m09-domain
Source: https://github.com/dojoengine/torii-core/tree/main/.agents/skills/m09-domain
Command: npx skills add https://github.com/dojoengine/torii-core --skill m09-domain-dojoengine

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Domain modeling guides teams to identify when a concept should be an Entity (identity matters) or a Value Object (interchangeable by value), establish invariants, and define clear ownership across aggregates, enabling consistent design decisions before coding.

Core Features & Use Cases

  • Pattern guidance: classify concepts as Entity, Value Object, Aggregate Root, or Repository, and map their ownership and invariants.
  • DDD alignment: provide prompts and templates to align domain concepts with Domain-Driven Design practices, events, and boundaries.
  • Practical templates: include Rust-pattern sketches for Id types, ownership, and aggregate composition.
  • Use Case: before implementing domain types, determine identity rules, invariants, and boundaries for safe persistence.

Quick Start

Describe a domain concept as an Entity or Value Object, and draft a Rust structure with an Id for an Entity or a simple, immutable wrapper for a Value Object.

Frequently Asked Questions about m09-domain

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I model domain entities and value objects in Rust?

Model domain entities in Rust by assigning them a unique Id type to track identity, and model value objects as simple, immutable wrappers where interchangeability depends on value rather than identity, establishing clear invariants and ownership.

What is the difference between an aggregate root and a repository in domain-driven design?

In domain-driven design, an aggregate root defines the ownership boundary and enforces invariants for a cluster of entities, while a repository handles the persistence boundaries and retrieval of those aggregate roots from storage.

When should I use domain-driven design patterns for structuring Rust applications?

Use domain-driven design patterns when you need to classify complex domain concepts, enforce strict invariants, and define clear ownership across aggregates before coding, ensuring consistent architectural decisions and safe persistence boundaries.

How do I enforce invariants and ownership across aggregates in Rust?

Enforce invariants and ownership across aggregates by designing domain types with clear boundaries, using Rust-pattern sketches for aggregate composition, and applying thinking prompts to align rules with Domain-Driven Design practices.

Can I use domain-driven design for defining persistence boundaries in Rust?

Yes, domain-driven design in Rust explicitly supports defining persistence boundaries by mapping aggregate roots and repositories, ensuring safe storage interactions through trace-up and trace-down guidance for domain types.

What are the limitations of domain modeling for Rust application architecture?

Domain modeling focuses on classifying concepts and establishing invariants before coding, requiring teams to invest in upfront design decisions for identity rules and boundaries, which may introduce overhead for simple CRUD applications.