使用颜色建模进行领域分析

要点

• 对企业应用进行领域建模的目的是为了支持企业运营
• 企业运营需要可追踪的业务流程证据链
• 支持企业运营的领域模型需要基于时标性（moment-interval）对象，它们呈现了了业务演化的过程
• 其他领域对象（实体、角色、描述）可以从时标性对象中衍生而来
• 为了具备更好的可视性，不同类型的领域对象可以使用不同的颜色来绘制

领域建模的方法有很多，在相同的领域问题上使用不同建模方法可以产出不同的模型。我经常听到这样的问题：如果确保建模流程的正确性？

这是一个很直观的问题，不过实际上它比我们所认为的要复杂得多。首先，我们要搞清楚建模的目的是什么。如果只是为了描述问题，那么就无所谓对错，只有从不同的角度获得的不同结果。不过，如果是为企业业务系统建模，那么问题应该变成：我们该如何保证模型能够支持企业的运营？

我将通过以下的例子来简要地解答这个问题。

在进行分析和建模前，我们要知道构建企业业务系统的目的是什么。企业业务系统一般是为决策者或管理层提供支持，然后从管理者的角度考虑问题，帮助他们理清真正的需求。

假设你是一个在线电子书店的 COO。有一天，客户向你投诉，他买的书少了一本，而且书的总价算错了，他为这些书多付了费用。在你着手去解决这个投诉之前，你要先确认这个客户说的是否是事实。你该怎么办？

简单地说，你需要知道客户的订单里有哪些书、客户付了多少钱，还要知道有哪些书被快递出去。不幸的是，因为受限于技术手段，你看不到过去都发生了什么。你不可能驾驶时间机器回到过去。不过，你也没必要这么做。你可以检查客户的订单，检查你的电子银行交易记录和快递发货单。

在检查了订单和发货单之后，你发现客户是在三天前下的订单，书店在昨天把这些书快递出去了。从订单上看，客户总共买了七本书，但是发货单上面只有送货地址、包裹编号、快递费和重量，没有任何与书有关的信息。于是，你认为应该找发货部门的人问问情况。

你根据包裹编号找到有关包裹的细节，确定了包裹里确实只有六本书。同时，你还发现，因为缺货，有一个延期的订单，也就是那个客户买的第七本书，正准备发货。

现在还剩下书的总价问题。从电子银行记录来看，除了快递费之外，客户总共支付了 132.5 元，而订单上的总价也是 132.5 元，说明客户并没有多付费用。

为了验证价格的准确性，你在网站上重新挑选了这七本书，看看总价是不是一样。让人感到吃惊的是，显示的总价为 128.3 元。经过一番仔细的盘查，你发现有一本书属于促销商品。那么现在的问题是，促销活动是从什么时候开始的？

市场部门向你出示了近期的促销计划，你发现那本书的促销是从昨天开始的。也就是说，客户是在促销之前下的单。

也许你觉得现在应该打电话给客户，向他道歉，跟他说明书的价格问题和促销活动的事情。

你不会觉得这些事情对于一个 COO 来说太繁琐了吗？当然，这只是个虚构的例子。但我们能够从中学到什么呢？

任何业务事件都应该保留某种形式的追踪数据。追踪数据可以用于追踪事件。正如上面的例子那样，你无法回到过去，但在某种程度上，你可以通过那些票据了解过去发生了什么。如果我们根据时间对数据进行排序，我们或许可以推断在过去一段时间内所发生的事情。

为什么数据证据链能够帮助我们追踪业务运营？

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

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

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

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

1. 如果我是付款方，我有哪些权利？
2. 如果我是收款方，我有哪些责任？

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

现在，我们把视角转回到 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），黄色表示角色，蓝色表示描述对象。

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

1. 首先，根据管理层和运营的需求确定需要追踪哪些事件。
2. 其次，识别出追踪事件和相应的时标性对象。
3. 识别出与时标性对象有关的实体（party、place、thing）。
4. 对于那些扮演多种角色的实体（party 实体一般代表人类），为每种角色抽取出角色对象。
5. 最后，使用描述对象为实体补足信息。

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

关于作者

徐昊，ThoughtWorks 中国的 CTO 和首席咨询师，同时也是 ThoughtWorks 技术委员会成员。他还是 BJUG（Beijing Java User Group）和 AgileChina 的创始人。

查看英文原文： Domain Analysis by Color Modeling