|
|
|
|
|
|
by aphelion
4317 days ago
|
|
|
So generate immutable ProductState objects that contain all parts of the domain model that can change over time, and maintain a mapping from SKU to the correct object. So GET /product/12345 returns UUID_1 at time A, when details of the offered item change at time B a UUID_2 gets generated and a new GET /product/12345 returns UUID_2. If you want to be really anal retentive, generate the product state objects with timestamps to compare to the Date header in requests and have a list of product states that have been referenced by a given SKU to traverse through to get correct product details even when the catalog changes between sending and receipt of the request. |
|
|
But that just recreates the very problem the author set out to solve, which is that you have to send increasingly huge sub graphs of the database with each order.
I assumed the direction he was going to go was to let the client send the at-the-time data back with each subsequent request for time consistency, but require them to pass a server-provided signature to keep them from making up prices, and saving the server from having to keep a time history of every case.