Crate Boundaries
Good crate boundaries make the project easier to change.
forge-domain
Contains pure domain types.
Examples:
- ProjectId
- ContinuityId
- EntityId
- EntityKind
- RelationshipKind
- Visibility
- Secret
- ChronologyEvent
- Mutation
Should avoid:
- SQL
- HTTP
- Axum
- Tonic
- UI code
- database clients
forge-application
Contains use cases.
Examples:
- CreateProject
- AddEntity
- AddRelationship
- RevealSecret
- RecordContinuityEvent
- AddCollaborator
Depends on:
forge-domain
forge-storage
forge-auth traits, if needed
forge-storage
Contains repository traits.
Example:
#![allow(unused)]
fn main() {
#[async_trait::async_trait]
pub trait ProjectRepository {
async fn get_project(&self, id: ProjectId) -> Result<Option<Project>, StorageError>;
async fn save_project(&self, project: &Project) -> Result<(), StorageError>;
}
}
forge-storage-postgres
Implements storage traits using Postgres.
Depends on SQL libraries and migration tooling.
forge-api-contracts
Contains request and response DTOs shared by HTTP, gRPC, web UI, and tests.
forge-api-http
The REST API crate.
Recommended framework candidates:
- Axum
- Poem
- Actix Web
forge-api-grpc
The gRPC API crate.
This can be added later with Tonic.
forge-webui
The browser UI.
Possible approaches:
- Leptos
- Dioxus
- Yew
- static frontend that consumes the API
forge-rules-core
Common traits and IDs for rules adapters.
forge-rules-dnd5e / forge-rules-pathfinder / forge-rules-hero
System-specific mechanics.
These should attach mechanics to project entities instead of owning the project model.