Data-Oriented Design in ORE Studio

The first statement is the founding principle of DOD. The five that follow are the operational axioms derived from it. Only the axioms produce review checks. The principle explains why the axioms hold; it is not itself a check, so never score it.

1. Data is memory — the principle. Code exists only to transform data from one representation to another. The representation decides the cost.
2. Access patterns drive layout. Organise data by how and when code reads and writes it together, not by real-world taxonomy.
3. Structure of Arrays (SoA) over Array of Structures (AoS). Prefer parallel contiguous arrays per attribute over arrays of fat heap-allocated objects.
4. Separate hot and cold data. Isolate state read or written on high-frequency paths from metadata read rarely or once.
5. Handles over pointers. Use keys, indices, and offsets instead of per-object heap pointers and object trees.
6. Batch over per-object. Write functions that process contiguous collections in bulk, not one call per object.

ORE Studio is a database-backed application with Qt clients and a quantitative engine on QuantLib. DOD is not one rule for the whole codebase. A review that demands SoA for a CRUD entity, or accepts a pointer graph inside a simulation kernel, has misread the regime.

A struct that rfl reflects for JSON has a hard shape limit that nothing in the type system expresses, and crossing it fails the build on MSVC with C1202 rather than with anything naming the field.

MSVC caps the recursive type-dependency graph. The count that matters is a struct's effective field count: its own direct fields plus every field of everything it flattens, recursively. The ceiling sits below 19 effective fields — sub-structs of 9 or fewer compile cleanly, and 19 in one effective literal does not.

Two consequences are not obvious and both have cost us builds:

• rfl::Flatten does not reduce the count. Flattening is recursive, so a parent of three Flatten members whose sub-structs hold 5, 9 and 5 fields still presents a 19-field literal. Flatten is a JSON-shape decision, never a decomposition fix.
• The limit is per reflected literal, not per struct or per translation unit. A single struct's literal saturates it regardless of what surrounds it, so moving a type between headers does not help and no compiler flag raises it.

The rule: keep every rfl-reflected literal at 9 effective fields or fewer, splitting a struct through field_group nesting rather than Flatten. Space the margin, not the limit. A 19-field struct is fragile — a twentieth field re-triggers C1202 — while nesting makes later fields free, because a new field joins a sub-struct that already has room.

This applies to any type rfl reflects: entities, their field_group parts, and hand-written message types. It is most often hit by a wide generated entity, which the field-group split exists to prevent.

The artefacts a review reads, per component under projects/ores.<name>:

• modeling/*.org — the codegen entity, junction, and field-group models (where the component is codegen-driven). The lookup_entity metatype is reserved in codegen but has no authored instances; do not hunt for lookup models.
• The domain C++ types they generate, or hand-written domain headers in the core facet. This generated representation is the core data model, designed for performance; the review target.
• The SQL schema the entity maps to: the CREATE TABLE statements generated under projects/ores.sql/create/<component>/.
• Repository and service signatures: how code fetches collections and looks up records.
• Kernel entry points and their inner loops, for Regime 1 components.

A component review produces, per component:

• A regime classification with the reasons (what is hot, what is cold, where the boundaries are).
• A findings table: severity (Critical / Important / Minor), effort (Small / Medium / Large), and the criterion each finding maps to.
• A per-regime score of 1-5 where the regime applies.
• An overall data-model verdict and a debt level of Low / Medium / High.

Scores are anchored, not arithmetic. Pick the row the review most resembles:

The debt bands follow the score: 4-5 is Low, 3 is Medium, 1-2 is High. A regime that does not apply to the component is unscored, not scored 0. Two reviews of the same component should land within one point of each other; if they do not, the classification or the evidence was unclear, not the scale.

Hot-path claims need evidence: the loop structure, a profile, or a benchmark. Without evidence, record a layout risk as an opportunity, not a defect. A finding that demands a transformation outside the component's regime is a review error, not a finding.