目前在做一个周期送的相关项目,现在碰到一些问题,我把我们现在的设计列一下,然后碰到的问题,看大家有没有好的办法。
前台条件,有订单 order ,订单所购买的商品 good ,对于订单按照周期送生成的 package ,一个 order 会有多个 package,一个 package 可能会有多件不同的商品。目前大体是按这种模式进行设计和处理的: 如何判断每个 package 的所属期数,因为周期送的话,配送时间是未知的,虽然是以一定的时间(星期或月或年)的纬度进行的周期,但是如果按周期时间进行累加的话,可能产生的实际配送时间与计算出来的时间有误差(比如计算出来的时间为节假日,暴雨)等原因会对于实际与送时间进行提前或延后。 目前我的想的法是,抽象出排期的概念,对于商品创建出比如 100 , 102 , 103 这种递加的,产生的 package 中包含了对应的商品和对应的排期,后期对于排期的配送时间进行维护,用于确认 package 的实际配送时间。一个 package 有多件商品,其中有一个主商品的定义,所有排期以它为准
目前碰到的问题: 1 、这种设计模式到后期扩展是否存在问题? 2 、因为周期送,会存在客户因特殊情况要求暂停配送或延至某天之后的有效配送时间进行配送。因为延期和暂停都是针对于未配送的所有配送单,哪么当达到延期后的时间点或恢复配送时会有问题。重新开始配送的 package 的配送期数和时间如何计算?目前的想法是,恢复配送后的算出第一次配送的配送时间点(有可能算不出来,就需要等)然后当有这个时间点的时候,再去计算下一张,直至算完。因为每个 package 的商品可能不一样,配送的排期数也可能不一样。
或者各位针对于这种模式有什么好的想法和思路吗?多谢各位!
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.