The atomised entity: a central row and its parts

An entity is a set of keyed facts, not an object. The facts that answer to one key are the entity. Nothing owns them, and nothing versions as a whole except the central row, whose version stands for the state of the whole.

The rule this page applies is in Data-Oriented Design in ORE Studio: the components are separate types, no aggregate type represents an entity, and no entity object travels. See also the book it cites, section 5.4 of Richard Fabian's Data-Oriented Design (2013), There is no Entity.

A field set earns a part when it has at least one of these.

• Its own multiplicity, so a row is absent, one, or many for one entity.
• Its own change reason, so it moves without the rest.
• Its own reader, so a consumer needs it and not the rest.

A field set with none of them stays a column on the central row. One row per entity, one change reason and one reader make it a column group in a table's clothes, and a part would buy a join and a message it does not need.

The split is by access, not by real-world taxonomy. Two fields belong together when the same write touches both and the same read needs both.

• The key is a UUID. One key shape serves every family, so a part and its central row join on one column.
• tenant_id and party_id. Isolation is by tenant and ownership is by party, and both are stamped from the session rather than from the caller.
• The natural key. The identifier the domain carries, such as the ORE id of a convention, is unique per tenant and party and is not the row key.
• The market-data reference. One address per entity, where the entity binds to market data.
• The change audit: modified_by, performed_by, change_reason_code, change_commentary and recorded_at. Every entity carries it, and Data-Oriented Design in ORE Studio's regime 2 says so.
• The version. It is the entity's own and no two entities share one.

The version is the optimistic-concurrency token, so the rules in Optimistic Concurrency Versioning govern who may move it and what a writer must claim to be allowed to.

• A part is named for its family and its own concern, such as tenor_basis_swap_pay_receive. The family comes first, so the owner of a table or a type is readable from its name.
• A part reaches its central row by the central key and by nothing else.
• A part is itself an entity. It carries its own audit record and its own version.

A part's version counts the changes to that part. The central version counts the changes to the entity, which is every change to any part plus the entity's own. The two are different sequences on different things and are never compared. A screen that shows both must say which is which. This is the distinction Temporal Composite Entity Versioning: Target State draws between a child's version and its parent's.

A write to any part bumps the central entity's version, in the same transaction. The transaction closes the central row's window and opens a new one at the same instant, closes the changed part's window and opens a new one, and leaves every unchanged part open.

Because the bump happens in the same transaction as the part write, no instant exists at which the parts and the central version disagree. That is what lets a read assemble the entity from the timeline alone, with no mapping table and no stored aggregate.

The row lock that serialises concurrent writers, the soft-delete symmetry so that removing a part bumps the version too, and the multi-level case are in Temporal Composite Entity Versioning: Target State.

Time is the link. The central row's validity windows partition time into spans in which no part changed, because any part change would have closed the window. Within a span every part's window covers the instant, so the parts that composed a version are exactly the parts current at that version's instant.

The read has two steps.

1. Take the central row, either by version or by instant. Its window gives the instant to resolve at.
2. For each part, take the row with the greatest version whose window covers that instant.

No link table is needed, because the windows already record which part versions composed which central version. The interval test generalises the as-of point query in Time and Timestamps: Architecture and Conventions from an instant to a window.

A date question resolves the central row at the instant first, and then the parts at the same instant. A cross-entity question resolves each entity at the one instant. Version numbers do not cross an entity boundary, so the instant is what aligns several entities.

The wire carries one typed array per part, aligned over one page. A part's fields never appear as nested objects inside another part.

The server keeps filtering, ordering, paging and the total, so the arrays stay aligned and the screen zips them for display. That is a projection, not a join. A screen whose rows span several entities is a read model, never a client join. See NATS entity protocol specification for the reads and the read model, and Polymorphic payloads over NATS for the one-array-per-type shape.

The list read carries the central row and the audit alone. A list that also carried every part would carry the whole entity population in one reply. The detail read is the one that pulls the parts.