Schema Architecture and Design Rationale

Vektagraf schemas are composed of moduleextension schemas and application schemas. This design was chosen for several reasons:

1. Composability — ModulesExtensions encapsulate reusable domain components.
2. Namespacing — ModulesExtensions avoid collision of types and models.
3. Incremental evolution — ModulesExtensions can version independently.
4. Clarity — The application schema integrates modulesextensions into a coherent domain.
5. Deterministic resolution — Imports and references are resolved systematically.

ModuleExtension Schemas

ModuleExtension schemas define:

• Reusable type definitions
• Reusable enums
• Reusable models
• Fundamental constraints
• Namespaces
• Cross-moduleextension references

These modulesextensions behave like packages or libraries in a programming language but are purely declarative and contain no executable code.

Design decision:

Keep modulesextensions purely structural. They should not embed behavior, so they remain portable and deterministic.

Example (excerpt only):

{
  "schema": "https://schema.vektagraf.com/ext/v1",
  "namespace": "ecommerce_core",
  "types": [
    { "name": "money", "base_type": "json" }
  ],
  "models": { ... }
}

Application Schema

The application schema integrates:

• Extensions
• Models
• Relationships
• Validation
• Provenance
• Vector fields
• File storage fields
• Encryption rules
• Multi-tenancy settings
• System logs, sessions, jobs
• Plugin declarations
• Indexing

Design decision:

The application schema is the single source of truth for the entire backend.

This allows Vektagraf to generate a complete runtime environment without human-written glue code.