Skip to main content
Version: v1.0.0(int)

Pharus Architecture — v1.0.0

v1.0.0 is the first step on the path toward the architecture described in the Full Scale version of these docs (use the version dropdown in the navbar to switch). It reshapes the current backend into a clear stack — domain components, a business logic layer, and a real public API — with the frontend reduced to a thin client. The database stays as it is. The point isn't features; it's groundwork — putting the codebase in a shape where later stages can each focus on one specific piece of the destination instead of fighting the foundation.

v1.0.0

The five layers​

  • L1 — Data: Single Postgres with platform.* and org.* schemas. Logical split today; physical multi-DB later.
  • L2 — Components: Thin domain APIs over the DB. One per domain. No cross-component calls, no constraints.
  • L3 — Business logic / workflows: 176 workflows composing L2 components. Owns transactions, business rules, typed errors.
  • L4 — Public API: REST/JSON. 176 endpoints, 1:1 with workflows. Zod-authored, OpenAPI 3.1 emitted.
  • L5 — Clients: Web app only in v1.0.0. Thin client over the L4 API.

See the implementation plan for the build-out tasks.

Principles​

  • L2 components are thin: just the DB API for one domain. No cross-domain calls. No constraints.
  • L3 owns all orchestration, business rules, and transactions.
  • The platform/org data split is logical only — same shared DB, separated by schema/namespace. Physical multi-DB belongs to a later stage.
  • Auth and tenant resolution are already in place (Firebase JWT + X-Org-Id → req.authUser + req.orgId).
  • Components accept a connection as a parameter; tenant context flows ambient via SET LOCAL app.org_id on that connection.
  • Single template (Anthem) only. J&B is a later stage.