如果您將此作為一個獨立的應用程序從頭開始創建，您就可能創建一組如圖 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（例如，顧客定義他們的交通工作所需的工作，并且安排預約以進行實施）。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
