因为数据不是随机挑选出来的。让我们回顾一下之前的检查过程，你最先检查的是订单和出货单。如果客户下错了单，而出货单显示有七本书被快递出去，那么你就没有必要为客户的疏忽负责了。所以，订单和出货单是企业事实上的法律责任基础。

在你确认公司负有责任之后，你通过包裹单检查流程的执行结果，验证 主要的业务流程执行结果 是否正确。也就是说， 数据是业务系统关键流程的执行结果 。

流程的执行结果有助于我们在不知道流程细节的情况下追踪和分析紧急事件。

不仅仅在一些极端的情况下(比如上面的投诉事件)，在任何常规的经济交易中，我们都需要弄明白几个问题。

如果我是付款方，我有哪些权利?

如果我是收款方，我有哪些责任?

这些问题只有在业务系统捕捉了追踪事件之后才有可能得到解答。所以，企业业务系统的一个主要目的是记录追踪事件，并用它们建立有效的证据链。

现在，我们把视角转回到IT服务提供商领域。作为一个业务分析人员，为了在IT系统里建立可追踪的证据链，你需要知道应该追踪哪些事件，以及这些事件留下了哪些痕迹。

一般来说，这些追踪事件有一些有趣的共性：它们都是时标性对象。建模的第一步是要找出这些时标性对象。通过组织这些时标性对象，我们就能够得到整个领域模型的骨架。

在确立了骨架之后，我们要完善模型的细节，让它能够更好地描述我们的业务概念。这次，我们需要往模型里添加一些实体对象。实体对象基于时标性对象进行操作或者被操作，或者被放置在时标性发生的地方。实体对象有三种类型： party、place和thing 。

基于这些前提，我们就可以知道这些实体对象是如何在各种流程里起到作用的。我们需要引入角色的概念，因为有时候同一种类型的实体对象在不同的流程里会扮演不同的角色。例如，在下图中，Employee实体在不同的场景里既可以是Distributor，也可以是Marketing Director。

最后，我们可以往 描述 对象里添加详细的实体描述信息。例如，如下图所示，Book对象可以只包含的基本信息，如标题、ISBN，而其他描述性的信息(作者、概要、目录等)可以被放在Book Description对象里。

我们使用“颜色对象建模”技术得到了一个领域模型。这些颜色最初由Peter Coad和他的合著者在“彩色UML建模(Java Modeling In Color With UML)”一书中推荐使用：粉红色表示时标性对象，绿色表示实体(party、place、thing)，黄色表示角色，蓝色表示描述对象。

通过对上述流程，不难总结出建模技术的次序和关键点：

首先，根据管理层和运营的需求确定需要追踪哪些事件。

其次，识别出追踪事件和相应的时标性对象。

识别出与时标性对象有关的实体(party、place、thing)。

对于那些扮演多种角色的实体(party实体一般代表人类)，为每种角色抽取出角色对象。

最后，使用描述对象为实体补足信息。

我们把管理层和运营的目标作为建模流程的初衷。所以，整个领域模型实际上都在围绕着“如何有效地追踪目标”这个问题而展开。这样的模型才能很好地支持业务运营。