（同時參見圖 6）：
將現有的應用程序和廠商軟件包分解成表示相關操作組的離散服務集（自底向上方法）。
從應用程序中將業務流程和規則抽象為由業務編排模型管理的單獨 BPM。
圖 6. 服務分解
所有的 OOAD 都同標識和定義服務有關；但是還需要具有更高層的觀點。此外，當 SOA 致力于比經典開發項目層次更高的開發時，就有了發揮其他創造性思維的空間。
直接和間接業務分析
通過項目相關人員的會談和 CBM 來進行 BPM 和直接需求分析是一個容易理解且非常合適的標識候選服務的方法。
過去的經驗表明，這條主要的途徑應該通過補充間接技術來加以改進。在選擇候選服務時，產品經理和其他業務領導應該進行協商。例如，什么是計劃付款和開票模型？應該商議假定使用正在構建中的系統的企業的組織結構圖。建議還考慮一下非 SOA 項目中任何現有的用況模型。用于對正在構造的系統進行營銷介紹的術語是另一個很好的關于服務操作候選者的來源（特別是動詞，很少關注營銷動詞�。�。
域分解
在 Endrei 中定義的域分解、子系統分析、目標模型創建和相關技術是 SOA 流程構造方法或服務概念化框架（它是基于 Levi and Arsanjani 先前完成的工作構建的）最有希望的提議。來自 SEI 的 FODA 工作也為這方面的討論做出了貢獻。
服務粒度
選擇正確的抽象級別是服務建模的一個關鍵問題。您常常會聽到進行粗粒度建模的建議。這有點過于簡單化了。您應該將其改為在不損失或損害相關性、一致性和完整性的情況下盡可能地進行粗粒度建模。在任何 SOA 中，都有細粒度服務抽象的空間（假定有業務要求的話）。由于 SOA 并不等同于 Web 服務和 SOAP，因此可以使用不同的協議綁定來訪問抽象級別不同的服務。另一種選擇就是將一些相關的服務捆綁成粗粒度的服務定義，這是門面模式的變種。
命名約定
應該定義企業命名模式（XML 名稱空間、Java 包名、Internet 域）。簡單的例子就是始終用名詞來命名服務，而用動詞來命名操作。這種最佳實踐來源于 OOAD 空間。
第一類 SOAD 原理
除了組合 OOAD、BPM 和 EA 技術之外，還有幾個重要的 SOAD 概念和方面有待充實：
服務分類和聚合
策略和方面
中間相遇流程
語義代理
服務獲取和知識代理
服務分類和聚合
服務有不同的用法和用途；例如，軟件服務可以不同于業務服務（如前面的圖 5 所示）。此外，還可以將原子服務編排成級別更高、功能齊全的服務。
服務組合可以通過可執行模型（如 BPEL 建模的模型）來加以簡化；這是傳統的建模工具和方法不能處理的事情。
策略和方面
服務具有語法、語義和 QoS 特征，所有這些都必須進行建模；正式的接口契約必須涵蓋的比 Web 服務描述語言
文章來源于領測軟件測試網 http://www.kjueaiud.com/
