（同时参见图 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 服务描述语言
文章来源于领测软件测试网 https://www.ltesting.net/
