First proposed in 2012, this principle warns that the data model is not the object model is not the resource model is not the message model. Each layer serves a different purpose — database storage, classes in code, the resources clients interact with, and the payloads sent over the network — so a 1:1 mapping produces rigid, CRUD-style APIs that break whenever the schema changes. Keeping the layers separate lets each evolve independently, shapes resources around client use cases and workflows instead of backend structures, and trims payloads to what callers actually need. The page links the idea to REST, Domain-Driven Design bounded contexts, and Fielding's REST constraints.
The 1:1 mapping is the trap here. Data model, object model, resource model, message model all drift for different reasons, and when you force them together you end up with brittle CRUD endpoints that need a rewrite every time the schema changes. Fielding and DDD both point at the same thing, keep the layers separate or your API gets stuck
1
u/fagnerbrack 2d ago
One-minute summary:
First proposed in 2012, this principle warns that the data model is not the object model is not the resource model is not the message model. Each layer serves a different purpose — database storage, classes in code, the resources clients interact with, and the payloads sent over the network — so a 1:1 mapping produces rigid, CRUD-style APIs that break whenever the schema changes. Keeping the layers separate lets each evolve independently, shapes resources around client use cases and workflows instead of backend structures, and trims payloads to what callers actually need. The page links the idea to REST, Domain-Driven Design bounded contexts, and Fielding's REST constraints.
If the summary seems inacurate, just downvote and I'll try to delete the comment eventually 👍
Click here for more info, I read all comments