canic_core/dto/mod.rs
1//! DTO boundary definitions.
2//!
3//! ## Design rules
4//!
5//! - DTOs are **passive transport types**. They contain no domain logic, policy,
6//! validation, normalization, or invariant enforcement.
7//!
8//! - DTOs do **not claim guarantees that Candid cannot enforce**. In particular,
9//! uniqueness, ordering, and keyed semantics are not preserved at the wire
10//! level and must not be relied upon.
11//!
12//! - All authoritative invariants (e.g. ownership, uniqueness, replacement
13//! semantics) live in **storage and ops layers**, never in DTOs.
14//! - Data exported from stable registries is treated as a **snapshot** of state,
15//! not a live or authoritative registry.
16//!
17//! - DTOs therefore prefer simple list representations (`Vec<T>`). When keyed
18//! data is needed, define small entry structs (`FooEntry`) instead of
19//! tuples or maps. More structured shapes are used only when they materially
20//! reduce complexity for consumers, not to mirror storage internals or
21//! reintroduce lost semantics.
22//!
23//! - Avoid `HashMap` in DTOs. Keyed semantics and ordering are not preserved at
24//! the boundary; use `Vec<...Entry>` or explicit list types instead.
25//!
26//! In short: stable storage is authoritative; DTOs describe how data is
27//! transported, not what guarantees it provides.
28
29pub mod abi;
30pub mod auth;
31pub mod blob_storage;
32pub mod canister;
33pub mod capability;
34pub mod cascade;
35pub mod cycles;
36pub mod env;
37pub mod error;
38pub mod http;
39pub mod icp_refill;
40pub mod log;
41pub mod memory;
42pub mod metadata;
43pub mod metrics;
44pub mod page;
45pub mod placement;
46pub mod pool;
47pub mod rpc;
48pub mod runtime;
49pub mod state;
50pub mod subnet;
51pub mod topology;
52pub mod validation;
53
54///
55/// Prelude
56///
57
58pub mod prelude {
59 pub use crate::ids::{CanisterRole, SubnetRole};
60 pub use candid::{CandidType, Nat, Principal};
61 pub use serde::{Deserialize, Serialize};
62}