I was listening to this podcast from 37Signals (Basecamp) about the Rails "delegated type pattern" and it reminded me of similar designs in Salesforce’s Knowledge and Files/ContentVersion models.
In both systems there is a separation between identity/structure and immutable content.
The Basecamp delegated type pattern operates like this:
1) Create an immutable record (the "recordable")
- Stores the content or versioned payload
- Never updated in place
2) Create a mutable record (the "recording")
- References exactly one recordable at a time
- Stores identity and operational metadata such as permissions/access, creator, timestamps, position in a hierarchy, state
- Acts as the stable query, cache, and API surface
3) Create event records
- Links a recording to a recordable at a point in time
- Indicate the action, such as created, updated, restored, archived
- This is to allow history queries
Now in Salesforce Knowledge we have:
- KnowledgeArticle acts as the stable pointer
- Each published revision lives in KnowledgeArticleVersion, which is append-only
- Historical content remains queryable with no change to past versions
In Salesforce Files/ContentVersion we have:
- ContentDocument is the persistent identity
- Each uploaded version is stored in ContentVersion
- The latest published version is referenced, but older versions remain intact
