Concepts

Granit is not a collection of independent utilities. Every design decision flows from a small set of principles: modules compose with explicit dependency declarations, data is always scoped to its tenant, events cross boundaries without coupling, and compliance is structural rather than bolted on.

Understanding these eleven concepts gives you the mental model to use Granit effectively and extend it without surprises.

How concepts connect

graph TD
    MS[Module System] --> DI[Dependency Injection]
    MS --> Bundles
    DI --> Config[Configuration]
    DI --> P[Persistence]
    P --> MT[Multi-Tenancy]
    P --> C[Compliance]
    MS --> Msg[Messaging]
    Msg --> WO[Wolverine Optionality]
    Msg --> C
    MT --> SM[Security Model]
    SM --> C

Start with the Module System — every other concept builds on it.

Core architecture

• Module System — [DependsOn], topological sort, conditional modules, two-phase lifecycle
• Dependency Injection — module service registration, Options pattern, PostConfigure
• Configuration — Options (startup), Settings (runtime), Module Config (frontend read-only)
• Bundles — meta-packages and the fluent GranitBuilder API for quick onboarding

Data and infrastructure

• Persistence — isolated DbContext, interceptors (audit, soft delete, versioning), automatic query filters
• Multi-Tenancy — three isolation strategies, transparent query filters, async-safe tenant context
• Messaging — domain events, integration events, transactional outbox, automatic context propagation
• Wolverine Optionality — Channel fallback, crash behavior, when you actually need a message bus

Security and compliance

• Security Model — JWT authentication, provider-agnostic RBAC, per-role caching, back-channel logout
• Compliance — GDPR and ISO 27001 enforcement as structural patterns

Architecture decisions

• Modular Monolith vs Microservices — decision framework, migration path, operational trade-offs