Read Models are best kept schemaless

As a general rule, it is better for persisted data or data exchanged between two services to conform to a schema. Adhering to a schema helps avoid a host of compatibility issues and reduces application complexity because the application can safely expect a data format.

An exception to this rule is Read Models.

Read Models hold autonomous data. Information needs to be self-contained, so content is typically denormalized. Data in JSON format, for example, would end up containing nested objects (data from different contexts).

user = {
  "name": ...,
  "email": ...,
  "addresses": [
    {
      "type": "HOME",
      "street": ...,
      "city": ...,
      "state": ...,
      "country": ...,
      "zipcode": ...
    },
    {
      ...
    },
  ],
  email_preferences: {
    "daily": {
      "send_at": ...,
      "to": ...
    },
    "weekly": {
      ...
    }
  }
}

Document databases are a good fit for storing such nested hierarchies. They are mostly schemaless, with optional support for specifying and validating data against schemas. Not having to enforce a schema opens up more database options for the application to choose from.

One of the objectives of using Read Models is to have excellent Data Locality and remove the need for any processing before dispatching the data. So Read Models store ready-to-ship information. It is easy to imagine different user interfaces needing to display the same data, but in different formats or with subtle variations. Managing schemas for these multiple data or transfer formats can quickly become tedious.

Data in Read Models is expendable, so a specific structure's importance is further diminished. Their information is consumed by sources like User Interfaces or external services, so they are expected to change rapidly.

Schema management is also monotonous because Multiple read models can be derived from the same data point, like an event or data update. For example, the frontend may request for the entire user record after a successful login, but an Admin page may need only a tiny subject to display in the listing.

So keeping Read Models schemaless and flexible helps applications remain agile. Maintaining schemas for expendable, volatile, repetitive Read Models is usually not worth the time and effort.

Related: