4 ms·

FTA: "To patch it up, we attach the product price to the order..." The author already discussed attaching the price to the product into a ProductPrice. His arg

FTA: "To patch it up, we attach the product price to the order..." The author already discussed attaching the price to the product into a ProductPrice. His argument continues that price is only one thing, there may be more. FTA: "If our analytics department needs to know the product category for their reporting, or if our accounting department needs to know cost-of-goods-sold for revenue calculations, we must attach these as well, as they may change over time. As these requirements grow, you end up sending more and more of the object graph attached to the order, just to maintain consistency for everything that happens after-the-fact." He's essentially extracted all this information out into its own class caleed "State" which can be referenced by a single ID and passes that along with his product, a ProductState if you will.

jonahx 12y ago
All of his examples should be solved at the domain level. They just don't have anything to do with REST architecture. The information doesn't need to be sent over the wire. There are many ways to solve it, but at the end of the day all that needs to be sent over the wire is the product and the time of purchase. Everything else can be deduced on the backend, and how hard that is to do will depend on how well you've modeled the concepts your interested in.
- devuo 12y ago
  Completely agree. It's problem at the domain level, and not in REST per se.
baddox 12y ago
> His argument continues that price is only one thing, there may be more. Indeed. A new model is needed, and that new model would have all the relevant attributes. I can think of two ways to do this (using ActiveRecord-ish naming conventions). One way would be to have an InvoiceRow to represent the presentational details of each row in an Invoice, like name and price, perhaps along with a reference to the actual model it came from, like product_id. The Product model could change, but the Invoice would still have all the InvoiceRows it needs to display and reason about that invoice without fear of mutation. Another way would be to have a robust versioning system. So a Product might have only an id, and there could be many ProductVersions that hold all the real info (name, price, etc.) and reference the same Product via product_id. ProductVersions would of course be immutable. Then the Order model in the example would return product_version_id, and could therefore look up the actual name and price at the time the order was made. For the narrow example from this article, I think the first example fits better and is much simpler.
- notdonspaulding 12y ago
  The "robust versioning system" system you mentioned is a specific application of the general solution he's suggesting in the article. Essentially every data model can "freeze" its current value at a point in time, be assigned a UUID, and always have the main product_id redirected to the most up-to-date value. You're taking his example too literally and solving for it alone. He's talking about adding a generic feature onto your entire REST API to deal with these issues in a consistent way.

jonahx 12y ago

All of his examples should be solved at the domain level. They just don't have anything to do with REST architecture. The information doesn't need to be sent over the wire. There are many ways to solve it, but at the end of the day all that needs to be sent over the wire is the product and the time of purchase. Everything else can be deduced on the backend, and how hard that is to do will depend on how well you've modeled the concepts your interested in.

devuo 12y ago
Completely agree. It's problem at the domain level, and not in REST per se.

baddox 12y ago

> His argument continues that price is only one thing, there may be more. Indeed. A new model is needed, and that new model would have all the relevant attributes. I can think of two ways to do this (using ActiveRecord-ish naming conventions). One way would be to have an InvoiceRow to represent the presentational details of each row in an Invoice, like name and price, perhaps along with a reference to the actual model it came from, like product_id. The Product model could change, but the Invoice would still have all the InvoiceRows it needs to display and reason about that invoice without fear of mutation. Another way would be to have a robust versioning system. So a Product might have only an id, and there could be many ProductVersions that hold all the real info (name, price, etc.) and reference the same Product via product_id. ProductVersions would of course be immutable. Then the Order model in the example would return product_version_id, and could therefore look up the actual name and price at the time the order was made. For the narrow example from this article, I think the first example fits better and is much simpler.

notdonspaulding 12y ago
The "robust versioning system" system you mentioned is a specific application of the general solution he's suggesting in the article. Essentially every data model can "freeze" its current value at a point in time, be assigned a UUID, and always have the main product_id redirected to the most up-to-date value. You're taking his example too literally and solving for it alone. He's talking about adding a generic feature onto your entire REST API to deal with these issues in a consistent way.