Skip to content

Data Architecture

Data Architecture

Managed PostgreSQL is the current-lean database engine (DR-005, open — ENG-01 §4); which cloud's managed service to use is a separate, also-open question (current lean: Azure Database for PostgreSQL — ENG-01 §4/Decision Register ENG02-25). Domain tables remain owned by their owning module — shared persistence utilities must not become a generic business repository (ENG-01 §6). PH-03 defines the canonical payment data model (Payment Request, Action, Leg, Execution Attempt, Provider Transaction) that every Product's data ultimately normalizes into.

Prisma Patterns

Prisma is the current-lean ORM/query-library and migration tool (DR-006, open — ENG-01 §4, ENG01-04), reflecting the parent PE company's shared platform stack. Tenant-scoping enforcement at the query layer is ENG01-04's deliverable — see MultiTenancy. Beyond that baseline, DragonPay-specific Prisma conventions (schema organization, migration review process, generated-client usage patterns) are not yet defined; they'll be established as ENG01-04 is executed against real PH module work, not invented ahead of that.

Migrations

Not yet defined — ENG01-04's Required Behavior calls for "migrations, transactions, immutable-record conventions, optimistic concurrency, IDs/timestamps, and domain ownership of tables," but the concrete migration-review/ownership process is a decision still to make once Prisma is actually wired up.

Performance

Not yet defined at the data-layer level. STD01-13 sets the general principle — "keep internal processing efficient by avoiding unnecessary network hops and repeated database lookups... instrument before optimizing" — but no DragonPay-specific query/index performance convention exists yet.

Schema

The canonical schema is PH-03's data model (Payment Request → Action → Leg → Execution Attempt → Provider Transaction), extended by each PH module that owns its own tables (Party/Payment Instrument in PH-05, Risk Decision in PH-06, Route Decision in PH-07, and so on — see each epic's own data-model tables). There is no separate "Schema" document beyond what each epic already specifies; this heading exists to point back to those rather than duplicate them.