如果您将此作为一个独立的应用程序从头开始创建，您就可能创建一组如图 8 所示的类。
图 8. 工作订单的类图示例
如果您将工作订单构造为一个 OO 应用程序，这些软件对象将包含所有必需的业务规则，并且理解应该遵循的业务流程。
然而，这种方法在实践方面存在着一些缺点：
许多步骤涉及与现有遗留系统和数据库（例如帐单编制、日程安排以及库存系统）的连接，它们不可能遵循 OO 范式进行设计（在这样的情况下，应用适配器或仲裁器会有所帮助）。
为了使系统尽可能地灵活，将一些规则外化是有帮助的，这样就可以在不更改代码的情况下修改流程或工作流。例如像下面这样的规则：
标准的 24,000 英里服务包括四公升油。只是在使用四升以上的油或顾客要求优质油（如合成油）时才应该收取额外的邮费。
在遗留应用程序中有一套工业标准为普通汽车维修活动进行劳务估价。除非维修人员收取的费用超过该估价的 X% 并且报告产生差别的有根据的原因，否则顾客就应该支付标准的劳务费。
如果超过估价的 Y% 以上，就应该联系顾客以进行确认。
SOAD 为这些问题提供了极好的解决方案。由于它基于相关的行为对服务进行分组，而不是进行封装（行为及数据），所以这组服务与业务对象略有不同。
例如，您可能将工作订单（Work Order）和工作订单项（Work Order Item）一起分到工作订单服务（Work Order Services），并且创建日程安排（Scheduling）、目录（Catalog）和库存（Inventory）服务。另外，因为没有服务实例，所以没有与服务之间的关系等价的东西。工作订单的服务模型可能看起来如图 9 所示。
图 9. 工作订单的服务模型示例
与 OO 范式不同，这个模型并不表示功能系统。既没有考虑流，也没有描述业务事件或规则。在 SOA 范式中，在服务外面维护的业务流程编排决定了执行服务调用的顺序和时间。
从概念上讲，从第一次顾客联系到完成工作和帐单支付的整个业务表示单个宏观层次的工作单元，并具有数天到数周不等的生命周期。毕竟，从企业的角度来看，工作单元会产生收入。
然而，实际出现的情况是在一段相对长的时间内单独发生的一系列集中活动，例如，定义活动、安排预约、选择零件和备件、进行维修活动等等。在 IT 系统中，没有实际的流程会持续几分钟以上；事件之间的业务流程状态以数据的形式保存在数据库中。
这种类型的流程可以用状态转换模型（例如 UML 中可用的）很好地进行表示。图 10 显示了用有限状态机（finite-state machine）方法如何对业务流进行建模的示例。它是在业务流程进行时工作订单的状态如何改变的高级视图。
图 10. 工作订单的业务流程模型
业务流程编排集中于状态之间的这些转变。单独的操作永久地记录相关的状态改变。
图 11 显示了部分编排的示例，其中包括图 10 所示的业务场景中的步骤 1 到 5（例如，顾客定义他们的交通工作所需的工作，并且安排预约以进行实施）。
文章来源于领测软件测试网 https://www.ltesting.net/
