-
Notifications
You must be signed in to change notification settings - Fork 546
Move rate-related package concerns to a RateEstimate/Shipment model #470
Comments
Can you put together a small UML type diagram to model the relationships between these objects? Additionally, we will want to nail down definition here. To me, I get a rate estimate for a We should also sync on the direction we are going internally. It would be great if we were aligned, but if it doesn't make sense that is also okay (although less preferable) |
Thanks Shopify team for contributing this awesome gem. Agree more with @jonathankwok. One shipment represents the delivery details containing several packages & origin/destination & shipping rates, but in my opinion one shipment should have many RateEstimate since one carrier has many service option such as 'Standard Shipping' and 'Express Shipping' etc. @RichardBlair What you defined for RateEstimate is really a RATE CALCULATOR instead of entity-object relationship. Thanks Shopify Team again. ActiveShipping Gem provides more insights for our team. |
@RichardBlair I've thought this out a bit more, didn't draw a diagram but I've tried to put it in the clearest way possible: A A We then operate with the This also gives us the flexibility of inheriting from We'd also attach shipping options to a |
Do you buy a label for a shipment, or for a package? Or are you thinking about modeling this as 1 Shipment but multiple packages for carriers that support more than 1 package for a single label? |
The latter - you can possibly have multiple packages for a single shipment but they'll still have only one "label" (that can be used on multiple packages within the shipment, e.g. FedEx multipiece shipment. So you'd purchase a label for a shipment. |
@jonathankwok I like where you are going with the idea of a Shipment. |
Discussion came up during #469, and a bit IRL:
Some concerns on the existing Package are not generic enough to be on the Package data model. For example, export reasons such as
gift?
orsale?
are more intimately tied to the Shipment itself, which should be concerned with the actual shipment of a package from an origin to a destination with all the packages contained.Similarly, information such as
oversized?
anddimensional_weight
requires the knowledge of a carrier to determine - what constitutesoversized
for UPS might not be oversized for USPS, for example. These can't live on the genericPackage
model.I'm proposing a new model - a
Shipment
model, that represents the physical act of sending Package(s) from an origin to a destination with all the shipping options that may be included. Within aShipment
model will be one or more Packages, which each have a 1-1 relationship with aRateEstimate
, since aRateEstimate
is calculated by taking in the attributes of the Shipment as well as the Package.Still a little amorphous in my head as to the exact implementation but just throwing these thoughts out there for discussion.
The text was updated successfully, but these errors were encountered: