データモデリング
レジャーデータは所有権,転送行動,許可制限およびクエリパターンの周りにモデル化されるべきです.監査可能性と決定的実行をサポートできる最小のチェーン上の表示を選択します.
ドメインとアカウント
- ドメインは管理およびポリシー境界を表示するために使用します.アカウントと資産識別子に表示されますのでドメイン名を安定させてください.
- 関連のない責任を持つ単一のアカウントを過剰に載せることを避ける.ユーザー,サービス,トリガー,オペレーター,料金のスポンサーのための別々のアカウントを使用します.
- コンフィギュレーションとテストでカノニカルアカウントおよびドメイン識別子を使用します. Iroha 名前はカノニカル解析後にケースに敏感です.
- テストと生産のアイデンティティは,名前,ドメイン,および構成ファイルパスで目に見えるように区別してください.
資産と NFTs
- フンジブルバランスと譲渡可能な量については,数値資産を使用する.
- NFTs またはドメイン特有のオブジェクトを使用して,独占所有の記録に.
- メタデータでのみ値を持つ状態をコードするのを避ける. 資産と NFTs はライフサイクルのイベント,転送セマンティック,メタデータでない許可チェックを提供します.
- 資産をアプリケーションに曝す前に,精度,供給政策,発行者の責任,および燃焼/薄荷管理機関を定義する.
メタデータ
- レジャーオブジェクトのコンパクト属性,例えばラベル,統合 IDs,ポリシーフラッグ,ハッシュ, URIs,またはコンテンツアドレス参照などのメタデータを使用します.
- メタデータキーが安定して文書化されているようにしてください. クライアントに依存した後にキー名を変更すると,移行の問題が生じます.
- メタデータに直接大きな文書,ログ,プライベートユーザーデータ,または高速アプリケーション状態を保存しないでください.
- メタデータは,チェーン外データを指す場合,コンテンツハッシュ, URI, SoraFS パス,明示的な参照,またはコンパクトコミットメントなどの検証可能な参照を保存します.
メタデータとレジャーストレージの選択肢および メタデータを参照.
モデルによる許可
- ビジネス・オペレーションを中心に設計する役割は,実装の便利性ではなく. 仕事やサービスの名前の役割は,幅広い技術能力の名前の役割よりも監査が容易である.
- ワークフローを満たす最小のオブジェクトに許可トークンを拡張します.
- ミント,バーン,ピアマネジメント,実行器変更,トリガーマネジメントおよびメタデータ変異のための許可を高影響の許可とみなします.
- 暫定許可のための明示的な撤回およびローテーション手順を追加する.
問い合わせの形
- アプリケーションが最も頻繁に必要とするクエリをサポートする識別子とメタデータキーを選択します.
- 幅広い結果セットをページに並べて,通常のアクションのために無制限のレジスタンス全体のスキャンを必要とするユーザーインターフェースを避ける.
- チェーン外のインデックスは,重要なアプリケーション行動のために使用されるたびに,レジャーデータやイベントから再構築可能なように保持します.