Skip to content
cccskills
FreePublished on GitHub

rust-contract-domain-modeling

Domain-driven modeling patterns for Axone contracts. Use when introducing domain concepts, encoding invariants, or deciding boundaries between domain, handlers, services, gateways, queries, and state.

The English summary is being prepared. Showing the original description.

See how to install

Files included (2)

  • SKILL.md2.6 KB
  • references/repo-patterns.md1.8 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Rust Contract Domain Modeling

Goal

Keep business invariants in explicit domain types instead of scattering them across handlers, query builders, or storage code.

Boundary Rules

  • domain/ owns business concepts and invariants.
  • handlers/ decode messages, orchestrate use cases, and shape responses.
  • services/ compose domain logic with environment-dependent enrichment or cross-module coordination.
  • gateway/ isolates external module interaction and protocol-specific I/O.
  • queries/ build external query payloads or request strings; they should not become the home of business rules.
  • state/ persists data and reconstructs domain values; it should not silently redefine domain invariants.

Domain Rules

  • Prefer constructors such as new or try_new that reject invalid states up front.
  • Use TryFrom when validating a parsed or transport-level representation into a domain type.
  • Keep domain methods deterministic and side-effect-light whenever possible.
  • If a value is reconstructed from trusted state, make that explicit with a constructor such as from_state.
  • Model canonical representations once in the domain layer, then reuse them everywhere else.

Patterns From This Repository

  • Case::new and TryFrom<Term> validate that a case is a ground Prolog dict before it can circulate as a domain object.
  • Constitution::try_new validates UTF-8, required predicates, and engine feedback before a constitution exists as a valid domain value.
  • Constitution::from_state reconstructs a previously validated value from storage without re-running external validation.
  • Decision::new captures an immutable decision snapshot from already validated inputs.
  • Authority::new canonicalizes a bech32 account into the DID form exposed by the contract.

Design Heuristics

  • Put parsing and invariant checks as close as possible to the creation of the domain object.
  • Keep handlers thin. If a handler starts accumulating validation branches, move that logic into a domain type or service.
  • Avoid passing partially validated strings through multiple layers when a dedicated type can encode the guarantee once.
  • Make invalid states unrepresentable where practical, especially for smart-contract-critical logic.

References

  • For concrete domain examples from this repository, read repo-patterns.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Best practices for designing CosmWasm smart contract APIs. Use when defining message types, designing execute/query interfaces, or optimizing API ergonomics.

The English summary is being prepared. Showing the original description.

axone-protocol/contracts123Updated Oct 14, 2026

Guide for writing Rust doc comments that produce accurate generated contract documentation. Use when editing Instantiate/Execute/Query/Response types or any public schema-facing API.

The English summary is being prepared. Showing the original description.

axone-protocol/contracts123Updated Oct 14, 2026

Guide for writing conventional commit messages. Use when committing changes, writing commit messages, or reviewing commit history.

The English summary is being prepared. Showing the original description.

axone-protocol/contracts123Updated Oct 14, 2026

Axone contract structure and Abstract SDK patterns. Use when scaffolding or refactoring contracts, deciding layer boundaries, wiring AppContract entrypoints, or adding module metadata and replies.

The English summary is being prepared. Showing the original description.

axone-protocol/contracts123Updated Oct 14, 2026

Axone deployment workflows with cargo-make, cw-orch, and Abstract. Use when publishing modules, installing them on accounts, running local chain tasks, or inspecting deployments.

The English summary is being prepared. Showing the original description.

axone-protocol/contracts123Updated Oct 14, 2026

Guide for regenerating Axone contract schemas and rendered Markdown docs. Use when contract APIs or metadata change, when checking generated-doc drift, or when preparing documentation commits.

The English summary is being prepared. Showing the original description.

axone-protocol/contracts123Updated Oct 14, 2026

See all skills by axone-protocol

Report a problem with this skill