DDD案例(1):从需求分析到领域分析(5)

在提名截止时间之前,获提名的员工可以取消票。取消后,系统会分别发送邮件给部门协调者与员工主管,只要任意一人批准了该取消请求,就认为取消成功,该票又会恢复到可用状态。在缺席截止时间之前,员工可以取消票。取消后,系统会发送邮件通知部门协调者和员工主管,但无须他们审批,而是直接由培训专员负责处理该票。处理票时,会先检查分配该票时设置的活动(action)策略,要么由系统自动处理,要么由培训专员处理该票。处理票有3种活动策略:


q将票分享给别的协调者;


q将票分配给员工;


q让票作废。


在培训开始前,不允许员工再显式地取消票。如果员工在收到票后一直未确认,系统会检查分配该票时设置的策略,要么由系统自动处理,要么由培训专员处理该票,处理票的策略与前相同。一旦培训开始后,就不再允许员工取消票,如果有事未能出席,应提交请假申请。


部门协调者在将票分配给员工后,也可以取消已经分配出去的票。不同截止日期的取消流程不同,如图20-21所示。


DDD案例(1):从需求分析到领域分析(5)


部门协调者取消票的流程与员工取消票的流程比较相似,不同之处在于取消票时无须审批,直接就可处理。在提名截止时间之间,处理票的活动策略有3种:


q备选名单先到先得;


q备选名单按优先级;


q手动从备选名单中选择。


这里的提名备选名单(backup)就是从之前设置的过滤器生成的提名候选名单中剔除掉已经被提名的员工列表后的名单。


培训专员也可以取消票,其流程如图20-22所示。


该执行流程与部门协调者取消票的流程几乎完全相同,这里不再赘述。


在分析培训流程时,我分别运用了服务蓝图和业务流程图展现了分配票、培训和取消票的业务流程,并根据不同阶段的业务目标确定了业务场景。


DDD案例(1):从需求分析到领域分析(5)


在明确票的分配业务场景下的业务服务时,我们发现关于票的分配存在两个不同的业务服务:


q分配票给部门协调者;


q分配票给部门员工。


票的分配目标不同,而行为都是分配,是否存在语义不清的问题?实际上,虽然都是对票的分配操作,但它们的业务含义与服务价值完全不同。获得票的部门协调者并非票的拥有者,不会参加培训,而是拥有了分配票的资格,可以将票进一步分配给员工。为避免混淆这两个概念,可以将分配票给部门员工的操作视为对员工的提名。这就明确了如下概念。


q分配票给部门协调者:获得票的员工为部门协调者,并非参加培训的员工。


q提名部门员工:将票分给部门员工,使得他(她)具备了参加培训的资格。


虽然都是部门员工,但是在分配票和培训的不同业务场景中具有不同的身份。明确这些身份(角色),可以更加准确地体现部门员工与培训的不同关系。


q候选人:利用过滤器筛选或直接添加的员工,都是培训的候选人。这些候选人具备被培训专员或协调者提名参加培训的资格,但并不意味着候选人已经被提名了。


q     被提名人:指获得培训票要求参加培训的员工,即被提名的对象。


q备选人:指备选名单中的员工,备选名单是提名候选名单中剔除掉被提名人的员工列表。


q学员:被提名人在收到培训票后确认参加,就会成为该培训的学员。


无论是明确“分配”的含义,还是进一步细化部门员工的不同身份,都是在定义和提炼统一语言。这些统一语言的确定需要即刻反映在业务服务图中。


票的取消业务服务图如图20-24所示。


DDD案例(1):从需求分析到领域分析(5)



上一篇:【云吞铺子】RDS for MySQL CPU性能问题分析(三)


下一篇:Microsoft Pix新功能超拉风 功臣非“边缘”AI莫属