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.