一段时间，我师傅大师经常找我们讨论TMS领域中的各种概念和领域设计，其中涉及到一些目前模型中不合理的地方。本着现实主义的考虑，对于TMS领域模型概念和用法的讨论，往往会受到一些防御和天生的反抗。不过因为TMS长期发展后，领域模型复杂而灵活。很多时候需要增加一些用法原则与避免相同的场景在不同项目中过大的差异。
首先讨论一下最近关注的点，签收。
签收首先是针对货物的，在TMS中，带货物属性的对象在TMS领域中主要有三个，SR, JOB, TO(预约)。这三个对象的定位主要是：
sr：上游下达的一次运输需求
job：给下游指派的一次运输指令
to(预约)：一辆车的一段运输
那么签收应该基于那个对象来做呢？从领域上来看很清楚嘛，基于sr做，也就是基于以上游的一次运输需求来做。
但是运输过程永远都没有这么简单，继续考虑两种特殊一些的情况。
特1：上游下的单很碎，拆分到了不同的出库仓，让客户签收多次显然不合适，那么在哪个点做合并呢？建议的做法是在sr生成时就合并掉，将复杂度和特殊性抛到接口这个万能的外挂中。感觉是OK的。不过这种合并仅限于出库仓在同一个大的园区中，如果确实从两个相隔较远的仓发货，那还是签两次吧。
特2：上游下的单很大，一次运不完，如果在一个签收单对应了多辆车的运输，显然也是麻烦的，不论是签第一车还是签最后一车都有交接责任不清的问题，这种情况回到前面领域模型的三个对象上来看，合适的似乎是to(预约)，不过因为系统的灵活性，一次预约实际上可以装多个客户的货，那么这个签收单实际上对应的应该是一个to(预约)中的一个sr。换句话说就是订单分预约货物打印。
基本上就是这样，如有特殊情况请一起讨论。
网友评论