Architecture Overview

ttrpg-forge should be organized around a system-neutral domain core.

A recommended high-level architecture:

ttrpg-forge
├── domain crates
├── application/service crates
├── storage crates
├── API crates
├── web UI crates
├── rules adapter crates
└── integration crates

Layers

Domain

Pure types and rules.

The domain should not know about HTTP, SQL, HTML, Axum, Tonic, Leptos, or authentication providers.

Application

Use cases and workflows.

Examples:

• create project
• add collaborator
• reveal fact or secret to player
• record continuity event
• search continuity state
• publish player-facing page

Infrastructure

Adapters for databases, search indexes, authentication, file storage, and message queues.

API

HTTP and gRPC entry points.

The API should call application services instead of directly mutating database tables.

UI

The web UI should consume the API or shared application contracts.

Rules Adapters

Rules adapters attach game-specific data to neutral narrative entities.

Examples:

D&D 5e adapter
Pathfinder adapter
Hero System adapter
Generic novel adapter

Important Boundary

The lore graph and continuity model should work without any rules adapter installed.