Entity Addressing on Bitsy Services Wiki

Relational vs. Object-Oriented Databases

Mon, 01 Jan 0001 00:00:00 +0000

The relational and object-oriented database camps disagreed about the most basic question a data store has to answer: what is an entity, and how do you point at one? The relational model says an entity is a row in a table, identified by the values of its primary-key columns and reachable only by querying that table. An object-oriented database (OODBMS) says an entity is an object with its own machine-level identity, reachable by following a reference – much like a pointer in a programming language.

Aggregate Root

Mon, 01 Jan 0001 00:00:00 +0000

The aggregate root is one of the central tactical patterns from Eric Evans’ Domain-Driven Design (2003). It is a deliberate, modelling-layer answer to the entity-addressing question: some entities should be referenceable from anywhere in the system, and others should be reachable only by going through one of those privileged entities.

An aggregate is a cluster of associated domain objects that should be treated as a single unit for the purposes of data changes. The aggregate root is the one entity in the cluster that the outside world is allowed to hold a reference to. Everything else inside the aggregate is addressed as (root, local id) – second-class within the application’s object graph, even if it happens to be persisted as its own row in a relational store.

Actor Model

Mon, 01 Jan 0001 00:00:00 +0000

The actor model is a model of concurrent computation in which every entity is an independently addressable actor with its own identity, private state, and behaviour. Computation proceeds by passing asynchronous messages between actors. There is no shared memory, no implicit container holding the actors, and no global lock – each actor is its own consistency boundary.

It is the maximal expression of the first-class-object stance from the broader entity-addressing tension: rather than putting many entities inside one process and addressing them by a local id, the actor model gives every entity its own globally unique identity and lets the runtime route messages directly.

First-Class vs. Second-Class Entities

Mon, 01 Jan 0001 00:00:00 +0000

In programming-language theory, an entity is first-class if it can be treated like any other value in the language: named with a variable, passed as an argument, returned from a function, stored in a data structure, and tested for equality. An entity is second-class if it lacks one or more of those affordances and must instead be referred to indirectly – through whatever container or syntactic construct privileges it.

The terminology is due to Christopher Strachey’s 1967 lecture notes Fundamental Concepts in Programming Languages, where he observed that in many languages “procedures are second-class citizens – they always have to appear in person and never can be represented by a variable or expression.” The phrase stuck, and the distinction it captures has turned out to be one of the most useful lenses for comparing language designs.

Resource-Oriented vs. RPC

Mon, 01 Jan 0001 00:00:00 +0000

Two architectural stances dominate the design of networked APIs. Resource-oriented designs (the REST family) give every conceptually distinct entity its own URI and address it directly using a small, uniform set of verbs. Remote-procedure-call designs (RPC: SOAP, XML-RPC, gRPC, JSON-RPC) expose operations on a service endpoint and pass entity identifiers as parameters.

The distinction maps cleanly onto the broader entity-addressing tension. REST treats each resource as a first-class object with a global, dereferenceable address. RPC treats resources as rows inside a service container, addressed by parameter rather than by URI.