Profile: Trading record
Table of Contents
This page is a named element-scope MASD profile instantiating ORE Studio Variability Model § "Profiles: naming a recurring configuration point". A model file binds to this profile (rather than authoring each feature individually) to guarantee the exact feature combination below, with no ad hoc variation.
1. Purpose
Models transactional trading data: the record a booking produces, as against the reference data every other profile in this catalogue describes. A lookup is read mostly and shared across the firm; a trading record is written on every amendment, curated per trading desk and workspace, and its writes are events other components react to. That difference is what this profile fixes.
It covers both halves of a booking. Trade carries the envelope — who the parties are, which book, where it has got to — and an instrument carries the economics. The two differ in how they establish their party and in how their domain struct is composed, so the profile deliberately fixes neither: a feature this profile does not list is the model's own choice, which is what lets one profile serve both.
What it does fix is the part they have no reason to differ on. Both are scoped to a tenant and a workspace. Both are written through NATS, so both should carry the generated eventing test that proves the pipeline end to end — Postgres trigger, event source, event bus, NATS publish — rather than leaving that to each author to remember. Neither generates a UI surface: the trade blotter and the per-instrument forms were hand-crafted in the removed desktop client and consumed the generated protocol.
2. Reference entity
trade — the first binding. The instrument families bind it as they are ported; they carry trading instrument today, which fixes the same tenant and workspace scoping but enables no facet, which is why sixteen instruments declare the eventing test by hand and ten do not.
3. Assignments
One row per feature this profile fixes a value for — any feature not listed here is left to the model's own choice. Party derivation is the notable omission: a trade takes its party from its book, an instrument from the session, and both are correct for what they model.
| Feature | Value |
|---|---|
| has_tenant_id | true |
| has_workspace_id | true |
4. Physical space
The eventing test is the facet this profile exists to fix. It proves the whole write path end to end – generator, service, mapper, Postgres trigger, event source, event bus, NATS publish – and it is the only test in the estate that writes a trade at all. Nothing else exercises the lifecycle trigger, so it stays on.
| Address | Enabled |
|---|---|
ores.cpp.eventing-integration-test |
true |
5. See also
- ORE Studio Variability Model — the axis definitions and feature bundles this profile composes.
- Profile: Trading instrument — the narrower profile the instrument families carry today.