2.1业务分析

2.1业务分析

2.1.1业务对象模型

业务对象模型即使对业务用例中涉及的业务实体进行建模,不过因为对象的建模过程实际上一般是在稍后的领域建模过程中建立的。因此这里仅仅列出了结果,具体的在建模过程—领域建模一节中再进行阐述。
下达入库指令业务对象模型
下达入库指令业务对象模型

2.1.2领域建模

2.1.2.1定义

领域模型是采用业务对象建立起来的一种模型,我们把领域模型当中使用到的业务对象称为领域类。一般来说,领域类有三种典型的形式:
 业务对象实体,表示业务中使用到或者产生的东西。如订单、账号、合同等。
 系统需要处理的显示世界中的对象和概念。如商家、买家、买家等。
 将要发生或者已经发生的事件。如购买、撤单、付费等。
现实世界中,每一项业务的运行都是由一系列的业务对象实体(包括人物和事物)、事件或者概念相互交互而完成的。领域模型建立的目的就是试图挖掘出这一系列对象之间的交互关系的“本质”。
如果说业务用例场景下的业务对象模型研究的是特定的业务实例(即业务对象结构如何实现该业务),那么领域模型研究的则是高于特定业务场景的一般规律(即视图定义出能够满足所有业务用例场景的对象结构)。可以说,领域模型是从所有业务用例场景对象交互模型中抽象出来的更高级别的业务对象模型;它表示了业务对象结构和交互的一般规律,揭示了业务运行的“本质”和“核心”。
建立领域模型需要对所有的业务非常了解,且对于项目型的公司而言,全业务领域模型国语困难和高成本。但是,我们可以放弃全业务领域,而只针对问题领域追踪某个我们关心的问题来建立对象(领域类)模型。
领域模型可以帮助我们理解问题领域中的关键概念和关键对象,帮助我们理解这些对象如何工作,以及如何解决问题。在大多数情况下,没有业务模型的指引而直接建立领域模型是比较困难的,而如果通过业务模型来推导,则事情要简单的多。因为在建立业务模型的过程中,我们已经能够体会到那些对实现业务最为关键和核心的问题,知道了关键的业务对象,也知道了业务过程中的交叉和重合,这些都对我们发现和建立领域模型相当有用。因此,我们可以从业务场景出发,针对某些重要的业务问题来建立领域模型,在用业务对象去验证该模型。
建立领域模型,我们需要经过提出领域问题,分析领域问题,建立领域模型和建议领域模型这些步骤。

2.1.2.2提出领域问题

我们需要发现和定义出关键的问题领域,例如在仓储管理中,客户的信息在在退货需要根据客户的退货地址进行退货、收货则根据收货地址进行发送货物、收货直配等业务上都需要使用到用户的信息。因此我们可以对客户档案问题进行领域建模。
问题一
客户服务部门需要根据客户的指令信息进行下达入库指令
问题二
收货主管要根据客户的入库指令指定对应的月台预约计划,安排收货任务。
问题三
送货司机根据客户的预约计划进行送货,送到指定的月台。
问题四
收货员根据客户的信息进行收货的查验,到货登记、质检,配盘、打印/粘贴标签、安排货位等操作。
问题五
叉车驾驶员根据客户信息进行货物入货。

2.1.2.3分析领域问题

根据业务用例场景得出,下达入库指令中涉及到的对象有下图这些。它们代表的含义是,经过业务用例场景后,客户合同、客户档案、上架标签、入库指令、月台预约计划,收货小条、到货登记表以及上架标签等这些业务实体在下达入库指令这个业务用例中被创建,使用或者修改。这些业务实体贡献于该业务用例。
下达入库指令业务对象模型
业务对象模型

它所代表的含义是,经过业务用例场景后,这些业务对象构成了客户信息。
领域变量
领域变量
领域变量

2.1.2.4建立领域模型

上述的领域变量就是领域模型的基本构成了。但是这些变量不一定是最终的结果。后续的过程中,根据业务场景逐步深入了解这些基本对象后,可以增加、减少、合并、拆分这些变量,形成最终的结果。
这些领域对象还比较粗略,如果仅仅想知道客户档案构成,到这里就可以结束了,可以在系统分析阶段再来详细的明确每个领域对象的详细构成。如果希望在这是了解客户档案的更多信息可以继续往下深入。

客户档案领域模型

客户档案领域模型

接下来,我们在遍历各部门中的相关业务场景,了解这些部门的业务将如何影响上述的基本对象的哪些数据,我们就能得到每个领域对象在不同场景中收到的影响。在综合考虑,构思可行方案,决定何时的业务对象和业务对象结构。
例如我们可以更加仔细分析客户基础信息这个领域对象的构成。
客户基础信息领域对象
客户基础信息领域对象