不应面向对象地针对业务行为建立模型！

在过去的几年中，我看到许多项目将几乎任何类型的业务需求都喜欢建立与需求原因无关的技术对象模型（后面可能简称对象模型）。在很多情况下，针对技术对象建立业务需求模型是相当不错的，我总体上对此表示赞同。但是，用受影响的业务对象来建立业务需求模型的话往往会使我们构建出一个糟糕且复杂的数据结构。下面我举一个简短的例子来阐明我的想法。

假设我们有一个软件项目。我们的目标是搭建一个为销售跑车的小型汽车制造商提供服务的在线销售系统。（有个设想也许是因为过去我曾在一家大型汽车制造商看到类似的问题。）

我们的这个在线销售系统用于处理汽车订单，因此我们可以为订单处理设计一个典型的技术对象（可以称之为汽车订单表），如下所示：

表1。

汽车订单表（CAR_ORDER）具有唯一的订单编号（orderID），汽车的型号类型(Model)，价格(Price)和颜色(Color)。在我们的案例中，上述对象所拥有的数据已经足够用来管理订单。但是，在一个要求灵活的软件项目中，业务需求往往会在开发周期中非常迅速地发生变化和发展。所以，假定在未来的某天，市场营销团队告诉我们，汽车的颜色只能在客户订购汽车的时候确定。我们相信这个新条件是必不可少的，我们开始通过添加新的属性来丰富扩展我们现有的技术对象模型：

表2。

我们的Web开发人员可以轻松地通过检查新标志位是否已经订购 (isOrdered) 来确定颜色选择器在GUI(Graphical User Interface, 图形用户界面)中是否仍然可用。

针对业务行为进行建模

到目前为止，我们所做的是通过更改数据库图表将新的业务行为添加到我们的技术对象模型中。这是一个明智的策略吗？

我想在此提出的替代方案是：设计一个业务流程模型，而不是对象模型。如果我们有一个工作流引擎，我们可以像这样对给定的需求建立模型：

现在我们已经将不同的业务状态建模成一个称为汽车订单的新业务流程模型。有关汽车是否已订购的信息已转移到BPMN 2.0（业务流程建模与标注·二代标准）业务流程模型中。工作流引擎可以读取这样的模型，并将新的业务流程实例与此模型同步。因此，当我们现在将技术对象模型与业务流程关联起来时，我们仍然可以继续使用我们上面提及的第一个版本的对象模型（见表1）。我们的网站开发人员可以简单地向业务流程引擎询问流程状态，以此确定是否可以使用颜色选择器。

....
// 使用ID编号载入一个业务流程实例...
workitem=workflowService.getWorkItem(id);
if ("Ordered".equals(workitem.getItemValueString("$workflowstatus"))) {
   ....
}

工作流引擎不仅打理着业务流程构成的工作流，而且还管理着流程的所有信息，例如业务流程实例的建立和订购日期以及流程中涉及的所有参与者。

以一个对象模型为基础建立多种业务模型

让我们进一步增加复杂性。有一天，我们的营销团队提出了另一个新想法：VIP客户！

VIP客户最晚可以在订购的30天后内改变汽车的颜色。回到面向技术对象需求建模的概念，这往往可能会出现糟糕的数据结构设计，如下所示：

表3。

我们添加了一个新的标志位，用来标示VIP客户以及与更改颜色相关的、可能用得上的其他数据。

（不要在此争论关于这个对象的数据建模，这仅仅是为了演示，我们都知道数据模型可以快速增长，并且可以用不同的方式进行设计。所以关于这个对象的数据建模部分不应该成为大家关注的焦点）。

即使我们将汽车订单表（CAR_ORDER） 分到不同的表中，现在它仍然看起来不太可靠。毕竟我们不能认为这是我们市场营销团队的最后一个想法。但是，如果我们使用工作流引擎，解决方案会是什么呢？这种开发策略看起来可是非常不一样的。

VIP客户的新要求确实只是另一个业务需求的案例。因此，我们可以创建一个反映这些新客户需求的不同流程模型。我们针对VIP客户的新流程模型可能如下所示：

这种另类的流程模型现在定义了一个新的状态预购（Pre-Ordered）。此任务包含一个计时器事件，该事件监视订单日期(orderDate)并根据模型定义的时间段自动更新订单状态。而且，我们不需要在这里改变我们的技术对象模型！我们只需使用不同的流程模型为VIP客户分配新订单。另外，我们的网站开发团队不需要改变任何东西。不过，如果订购状态(Ordered) 被选中的话，颜色选项则将被隐藏。这一切都是由我们的新流程模型定义的，并且可以由工作流引擎进行控制。

以一个流程为基础的多种观点

我想再次扩展这些需求，以深入探讨业务流程管理的想法。我们的市场营销团队提出了一个新的家庭车系列。当然了，这是一个奇特的，伟大的新想法！要求即使在订购了汽车之后，家庭也可以改变汽车的颜色 - 但这一改变必须与生产团队达成一致。我会在这里为您提供一个更疯狂的数据模型设计草案。让我们看看这个新的业务流程模型需要反映的需求：

我们在这里所做的只是简单地将任务订单转移到单独的通道中。业务流程建模与BPMN 2.0模型中的通道定义了业务流程中的特定角色。通过将任务转移到一条通道中，任务将会分配给不同的参与者 —— 在我们的例子中这个参与者是生产团队。

以人员为中心的工作流引擎（如Imixs-Workflow）专门针对以用户为中心的行为进行建模。每个任务可以分配给不同的人员，组或角色。访问级别可以通过将读取和写入访问权限分配给不同的参与者从而更以精细的方式进行建模。

因此，我们在这里所做的只是将订单Ordered 任务的写访问权限改为我们的生产团队。这意味着只有生产团队才能在订单Ordered任务期间修改流程实例。

对于我们的Web开发人员来说，上述意味着他们可以询问工作流引擎是否仍允许当前用户（客户）更改业务流程的数据：

....
// 通过ID编号载入一个业务流程实例...
workitem=workflowService.getWorkItem(id);
if (("Ordered".equals(workitem.getItemValueString("$workflowstatus")))
    &&
    (workitem.getItemValueBoolean("isAuthor"))) {
   ....
}

通过这个新的流程模型，生产团队的成员将看到颜色选择器，并且即使在汽车已经订购时也可以更改数据 —— 但是家庭成员可能只会看到关于询问销售代理能否进一步更改车身颜色的信息。

请注意，我们仍然没有对原始的数据模型进行任何更改，但通过使用工作流引擎，我们用三个独立的流程模型解决了三个非常不同的需求！

结论

我想在此展示的是，在业务流程中对业务需求进行建模可以像在对象模型中那样高效得多。借助工作流引擎，您可以在不更改技术数据模型的情况下更改应用程序的实现。目前，在需求灵活的开发项目已经变得重要性不言自明的情况下，软件系统应该能够满足独立于技术对象模型的不断变化的需求。工作流引擎和BPMN 2.0是对面向对象业务应用程序的强大扩充与发展。