1.业务背景：

• 1.1:领料业务流程

• 1.2:退料业务流程

•  1.3:业务现状: 

• 针对上面加工台加工人员的领料需求，退料需求,现在的做法是生成领料需求单和退料需求单，然后作业流转人员根据领料需求单和退料需求单去进行领料和退料操作。这么实现,好像没什么问题，但如果从长远角度来看，这个存在业务耦合和业务拓展性的问题

• 1.4:现状分析：

• 单据：可以理解为需求,比如:生产过程中，产线作业人员有领料,退料的需求，统一可以抽象为一种需求的单据，举例:产线作业人员A,发现我现在没有原料可以使用了，我需要叫料，此时就会生成一个领料申请单,单据保存的仅仅只是哪个产线,哪个任务,在什么时间点,发起了一个叫料的需求,具体后面谁会帮我承接这个单据,谁去操作领料或者退料，产线作业人员不需要关心。所以把单据贯穿整个领料或者退料业务流程不太合适.

• 拓展性：领料和退料业务场景其实有相同之处，就是发出需求，然后处理这个需求,那为什么不抽象一个公共模型去处理这种类似的场景呢？现在如果我要查询领料和退料的情况，我要分别查一下领料和退料需求单，如果我后面新增了1种场景叫"退料差异"，这种场景和领料,退料场景类似,如果我要查询“退料差异”的情况，我还要再去查一下"退料差异"单的数据。何必呢？我把这些场景抽象成公共模型后,我是不是只要对这个公共模型去操作就行了。而且后面这个公共模型还可以独立出来，做一个类似于“任务平台“的东西，我任务平台提供通用API跟外部做交互，而内部则根据不同的业务场景类型通过策略模式去实现各个业务场景的操作。

• 1.5:业务价值：

• 系统层面上的松耦合,满足后续业务任务场景的拓展性,后续业务可以随便新增类似的新的业务场景,系统都能满足

2.任务模型-实体生命周期

• 实体E-R图：

3.系统/服务交互图