DocumentationSystem Design
DOCS

System Design

The whole platform in one place: one package, fourteen core modules across nine domains, the contract spine, the adapter ports, the async seams.

Introduction

One published package, @openora/core. Fourteen core modules across nine domains, plus one gated add-on. The contract spine, the plugin host, twenty-four adapter ports, three async seams, and how a consumer overlays proprietary code on top.

The numbers below come from docs/catalog.json: 15 registered modules (14 core, 1 add-on), 24 adapter ports, 49 domain events, 115 HTTP routes including health.

The whole system

Rendering diagram...

Distribution model

@openora/core ships under one fixed version - no cross-domain version skew. A consumer installs the one package; its subpaths expose every module. The runtime contract is composed only in the consumer's createApp() call, via composeContract - that is what keeps every subset independently usable.

Rendering diagram...

Ports and adapters

Rendering diagram...

AUDIT_WRITER is a sealed token - it can be bound once, by its owning module, and never rebound by an overlay. It is the only sealed identity with a live implementation today; the rest of the sealed list is a set of documented regulatory placeholders.

Money and event lifecycle

Rendering diagram...

Reference: domain, modules, tables, routes

Route counts come from docs/catalog.json - 115 routes in total, health included.

DomainModulesTablesRoutes
@openora/core/iamiam (admin roles, perms, invites)admin_role / admin_role_assignment / admin_role_permission / admin_invitation16
@openora/core/auditaudit (append-only log)audit_log2
@openora/core/admin-consolebackoffice read APIowns none - reads via ADMIN_USER_DIRECTORY + ADMIN_WALLET_REPORTING6
@openora/core/pamidentity, profile, player-note, tag, player-managementuser / session / account / twoFactor / verification, player, player_note, tag31
@openora/core/compliancecompliance (RG, KYC, geo)geo_rule, user_limit15
@openora/core/walletwalletwallet, wallet_transaction, auto_withdrawal_rule11
@openora/core/casinogaming, lobbyGame / GameRound, LobbyCategory / FeaturedSlot9
@openora/core/engagementchat, notificationsChatRoom / ChatMessage, notification14
@openora/core/cmscmspage / banner10

player-management is the gated add-on inside pam; it loads only when listed in the OSS_ADDONS allowlist, and accounts for 7 of that domain's 31 routes.

Cross-domain edges

Every edge below is lint-enforced by two independent gates: fast import linting on each edit, and a whole-graph dependency check that also catches transitive edges, barrel laundering, and dynamic imports.

From to ToChannel
iam to identitydependsOn (load order)
gaming to walletWALLET_COMMANDS synchronous command port (same tx, atomic)
player-management to profileread-only @openora/core/pam/schema
lobby to gamingread-only @openora/core/casino/schema
any to anydomain events via EventBus (49 topics) - never money

Twenty-four adapter ports and three async seams - MESSAGE_BROKER, JOB_QUEUE, REALTIME_TRANSPORT - plus the transactional OUTBOX carry everything else. Money and needed-now reads stay synchronous and transactional; nothing else imports another module's internals.

Updated 1 month ago