Data Model

DSM models shared state as immutable entities attached to explicit collection locators.

Entity Contracts

• Register and CRDT update types implement DsmEntity<E>.
• Lease types implement LeaseEntity<E>.
• The runtime updates metadata by creating a new value object through methods such as withMetadata(...) or withLeaseState(...).

This keeps mutation predictable and serialization stable.

Collection Locator

Every collection is addressed by:

• tenantId
• applicationId
• collectionId

DSM does not rely on an older namespace compatibility layer. Those identifiers are the address space.

Metadata

Entity metadata is stamped by the runtime and travels with the entity. That metadata is what allows replication and deterministic conflict handling to work across nodes.

Immutability

DSM expects immutable value objects, usually Java records. This matters for two reasons:

1. replication logic can reason about value identity safely
2. codecs can serialize and deserialize entity state without hidden in-place changes

Conflict Handling

Registers use deterministic metadata-driven resolution. Lease collections add fencing semantics. CRDT collections merge toward a convergent state instead of relying on last-writer-wins alone.

Practical Guidance

• Keep entities small and purpose-built.
• Put business payload and runtime metadata side by side in the record.
• Avoid storing large mutable graphs inside DSM entities.
• Treat DSM data as control-plane state, not as your primary application database.