Data-oriented design organizes software around the data a workload actually transforms and the way that data moves through memory, rather than beginning from a preferred object hierarchy.

Its central question is not “which data structure is theoretically elegant?” but “which data is needed together, in what order, and how often?”

Start from access patterns

If one hot loop repeatedly processes positions but rarely touches names or metadata, placing every entity field together can make the processor fetch mostly unused bytes.

Separating frequently processed fields can reduce the working set and improve spatial locality.

Reduce indirection and unnecessary work

Pointer-rich object graphs can introduce unpredictable memory accesses, allocation overhead and repeated traversal. Flattening or indexing relationships can sometimes turn scattered work into linear passes over compact arrays.

The trade-off is that the resulting representation may be less directly shaped like the conceptual domain model.

Data-oriented does not mean one layout

AoS, SoA, packed indices, sparse structures and pointer-based structures can all be appropriate. The useful representation follows measured workload characteristics rather than a universal rule.

Measure before and after

Data-oriented changes can make code faster but can also make it harder to understand or update. Profiling should establish a real bottleneck, and benchmarks should verify that the redesigned representation improves the complete workload that matters.

The design principle is therefore empirical: understand the transformations, choose data layouts that serve them, and validate the trade-offs on real hardware.