任务领域边界问题的定义

需求背景

网约车平台在需求高峰期司机不足时，会针对司机会下发各种任务奖励活动，来吸引司机上线平台进行接单。

当城市独立运营，网约车平台基于城市划分多个法人主体时，给司机发放的金钱奖励，会由公司总部和城市运营商一起进行承担。

基于以上述求，业务提出了一个需求，在配置各城市的司机任务时，如果司机完成了任务（比如：每完成一单或者几单，就给司机发放一定的奖励），奖励的发放应该由司机所属的城市运营商和总部一起按照一定的比例发放给司机。

需求已经非常明确了，这个技术解决方案的冲突在于司机所属的运营商数据到底由哪边提供？

司机任务团队，也是这个需求主体承接的团队。

运营商的配置也需要体现在任务配置上，但是司机完成订单时，应该由哪个运营商和总部一起来承担这个费用？他们觉得这个数据应该和订单强绑定，司机在每完成一个订单时所属的运营商可能都会发生变化，所以这个数据应该属于订单领域，记录在订单的明细数据中。

他们提出这个观点有如下几个立场：

当前任务系统，没有关联订单的明细数据，而当前任务奖励的发放都是在订单完成的时候触发，每次完单进行司机的任务奖励计算时，他们本身就要查询订单的明细数据，所以他们自然而然的就会想到这个数据从订单侧获取最方便。
任务会在每次司机完单或者任务结束的时候，会把前面发放给司机的任务奖励重新再计算一遍，解决司机前面任务奖励漏算或者系统异常等特殊场景，提高系统的鲁棒性。这时，司机对之前任务进行批量重算时，从订单上获取运营商数据，可以保持现有链路不变，性能也不受到影响。
司机当前所属的运营商或者其历史变更的运营商，这个数据应该由运营商团队进行承接。但是司机任务的奖励发放属于核心业务系统，而运营商系统一直是非核心业务系统，他们觉得核心业务系统不应该依赖非核心业务系统。同时，运营商团队只有司机当前所属运营商的实时数据，没有关联的历史变更数据，如果要做觉得工作量还挺大。

运营商和订单绑定时，那么订单的运营商数据应该从哪边提供？

订单本身和司机的运营商并没有强关联的关系，订单团队也不想在司机接单或者完单的时候，再去外部系统查询司机的运营商数据，这样会增加核心链路的耗时。

那么运营商数据从哪里获取？

派单系统： 派单在完成订单和司机的匹配时，告知订单系统接单的司机信息时，就带过去司机所属的运营商信息。

派单系统的司机运营商数据，需要在司机上线接单时，从运营商管理系统查询。

整体的数据流程如下：

运营商管理系统 -> 派单系统 -> 订单系统 -> 司机任务系统。

冲突点：

原始的需求，只是在司机任务配置时，新增一个运营商供补的要素，最终却要牵连整个交易核心链路上下游全量配合完成变更。

提出质疑：订单和司机所属运营商完全不相关，为什么要把司机的运营商与订单进行强关联？

如果司机所属的运营商数据不放到订单身上，那应该放到哪里？还是要回到问题的本质，这份数据应该归属到哪个领域进行管控？

为什么属于运营商管理领域的能力，最后要外放，大家没有达成默契，反而要推脱到其它系统来解决？

以技术具体的实现作为合理的依据。司机任务当前现状就是通过订单获取司机的接单数据，惯性思维那司机的所有信息都应该通过订单获取。
没有深入思考技术实现的成本。技术人员评估时，只是从表面上觉得从运营商管理获取数据，技术成本较高，并没有仔细评估实现的复杂性，就妄下结论觉得成本很高。如果技术成本确实很高，那可以考虑一下折中的方案，否则架构设计就不是合理的。

最终定的方案如下：

从交互的复杂性来看，前期设计方案的整体链路更复杂，需要依赖大量不必要的系统进行透传。

变更后的方案，数据的生产方和提供方统一了，链路更加清晰明了。
前期设计方案不合理的点，在于数据的生产方和数据方责任归属不统一，司机所属运营商的数据由运营商系统生产后，最终由派单系统和订单交易系统给司机任务提供，领域边界不明确。

运营商团队，之前要推脱这个事情，最主要的原因是：

解决方案如下：

考虑技术方案的时候，不要一开始就套用现有的技术链路。这也是开发人员最容易犯的毛病，现有的链路不见得就是合理的，也许只是在当前的背景前提下做出的选择。如今，时间和条件都发生了变化，为什么还要套用以前的方案呢？应该用当前的背景和现状，来评估当前最合理的方案。
不要用技术实现来绑定架构设计的合理性。对于研发的同学，经常会考虑技术实现怎么简单，怎么来？而不是怎么合理，怎么来？当然，架构设计除了考虑合理性之外，也是会考虑技术实现的成本。如果技术成本过高，也会综合平衡架构的合理性和技术实现的复杂度。