Data-Oriented Programming with TypeScript Generics

A class-oriented Order binds data and behavior into one object: pay() and ship() live on the instance, private fields protect internal state, and correctness relies on every caller going through the class's methods rather than touching fields directly. This works cleanly inside one process, but the moment the order needs to cross a boundary — serialized into a queue message, stored as a database row, sent over HTTP — the class disappears. What arrives on the other side is a plain object with the public data and none of the methods, and now two different code paths need to know how to handle "an order," one with behavior and one without.

A data-oriented Order is a plain, immutable object with no methods at all — payOrder(order) and shipOrder(order) are separate functions that take an order and return a new order. There is exactly one representation of an order, and it survives a queue, a database round-trip, or a network call unchanged, because it was never anything more than data to begin with.

A generic Entity type lets many different kinds of data share a common contract (an id, a version, a createdAt) without inheritance or a shared base class. Unlike a class hierarchy, where Order extends BaseEntity ties every entity to one rigid ancestor, a generic type is structural — anything with the right shape satisfies it, and adding a new entity kind never requires touching an existing one.

The practical payoff shows up in functions that operate generically across entities: a function that bumps an entity's version and stamps an updatedAt field can be written once, typed as operating on Entity of T, and reused for orders, users, or invoices without any of them needing to inherit from anything.

An order's status is not just a string — it's a finite set of states, and the transitions between them are exactly the business logic worth protecting with the type system. A discriminated union (a status field with a fixed set of literal values) lets TypeScript narrow the type inside a switch statement, and an exhaustiveness check using the never type turns "we added a new status and forgot to handle it somewhere" from a runtime bug into a compile error.

This is the single most valuable technique in data-oriented TypeScript: model every meaningful state as a literal in a union, then let the compiler enumerate every place that switches on it. A new status added to the union will fail to compile everywhere it isn't handled, before a single test runs.

Data-oriented modeling earns its keep for anything that crosses a serialization boundary — API payloads, queue messages, database rows, Redux-style state — because plain data survives those boundaries without translation layers. It's a worse fit for genuinely stateful, encapsulated components with real invariants to protect internally, like a connection pool or a caching layer with eviction logic — those benefit from a class's ability to hide implementation details behind a narrow public interface.

The test is not "is this object-oriented or functional" as an ideology — it's "does this data need to leave the process," and if the answer is yes, model it as plain data with pure functions from the start rather than retrofitting a class later once the serialization mismatch causes its first production bug.