所有的 OOAD 都同标识和定义服务有关；但是还需要具有更高层的观点。此外，当 SOA 致力于比经典开发项目层次更高的开发时，就有了发挥其他创造性思维的空间。

    1.直接和间接业务分析

    通过项目相关人员的会谈和 CBM 来进行 BPM 和 直接需求分析是一个容易理解且非常合适的标识候选服务的方法。

    过去的经验表明，这条主要的途径应该通过补充 间接技术来加以改进。在选择候选服务时，产品经理和其他业务领导应该进行协商。例如，什么是计划付款和开票模型？应该商议假定使用正在构建中的系统的企业的组织结构图。建议还考虑一下非 SOA 项目中任何现有的用况模型。用于对正在构造的系统进行营销介绍的术语是另一个很好的关于服务操作候选者的来源（特别是动词，很少关注营销动词！）。

    2.域分解

    在 Endrei中定义的域分解、子系统分析、目标模型创建和相关技术是 SOA 流程构造方法或 服务概念化框架（它是基于 Levi and Arsanjani先前完成的工作构建的）最有希望的提议。来自 SEI的 FODA 工作也为这方面的讨论做出了贡献。

    3.服务粒度

    选择正确的抽象级别是服务建模的一个关键问题。您常常会听到 进行粗粒度建模的建议。这有点过于简单化了。您应该将其改为在不损失或损害相关性、一致性和完整性的情况下 尽可能地进行粗粒度建模。在任何 SOA 中，都有细粒度服务抽象的空间（假定有业务要求的话）。由于 SOA 并不等同于 Web 服务和 SOAP，因此可以使用不同的协议绑定来访问抽象级别不同的服务。另一种选择就是将一些相关的服务捆绑成粗粒度的服务定义，这是门面模式的变种。

    4.命名约定
    应该定义企业命名模式（XML 名称空间、Java 包名、Internet 域）。简单的例子就是始终用名词来命名服务，而用动词来命名操作。这种非常好的实践来源于 OOAD 空间。

    第一类 SOAD 原理

    除了组合 OOAD、BPM 和 EA 技术之外，还有几个重要的 SOAD 概念和方面有待充实：

    1.服务分类和聚合
    2.策略和方面
    3.中间相遇流程
    4.语义代理
    5.服务获取和知识代理
    6.服务分类和聚合
    7.服务有不同的用法和用途；例如，软件服务可以不同于业务服务（如前面的 图 5所示）。此外，还可以将原子服务编排成级别更高、功能齐全的服务。

    服务组合可以通过可执行模型（如 BPEL 建模的模型）来加以简化；这是传统的建模工具和方法不能处理的事情。

    1.策略和方面

    服务具有语法、语义和 QoS 特征，所有这些都必须进行建模；正式的接口契约必须涵盖的比 Web 服务描述语言（Web Services Description Language，WSDL）的多。因此， Web 服务策略（WS-Policy） 框架是一个重要的相关规范。

    除了已经制定的良好 体系结构可跟踪性原则之外， 业务可跟踪性也是一个理想的品质：应该有可能将所有的运行时构件直接与非技术领域专家可以理解的语言联系起来。这对于直接在业务和服务层公开的抽象非常重要。Sarbanes-Oxley (SOX) 法案（请参阅来自 Astor的文章）是需要这种业务可跟踪性的业务驱动程序的一个例子。

    2.流程：中间相遇

    在真实世界中，并没有全新的项目，必须始终考虑遗留系统（ 遗留系统是现有系统的同义词）。因此，需要 中间相遇的方法，而不是单纯的自顶向下或自底向上的流程。

    在设计取决于现有的 IT 环境而不是现在和将来的业务需要的情况下，自底向上的方法往往会导致不好的业务服务抽象。而自顶向下的方法可能会产生不足的非功能性需求特征，并且损害其他的体系结构品质因素（例如因域模型中缺乏标准化而导致的性能问题），另外，也会在服务和组件中产生不匹配的不良问题。

    3.服务获取和知识代理

    这是一个知识管理和生命周期问题：如何成功地准备好服务并且使其在概念化之后可以重用？

    应该将重用看作是标识和定义服务最主要的推动标准之一。如果组件（或服务）不可能重用，就不无法将其作为服务进行部署。它可以连接到另一个与企业体系结构相关的服务，但是不能单独作为一个服务而存在。

    然而，即使从开始就计划好了重用，还必须形式化服务获取流程。由多个使用者使用服务是明确的 SOA 设计目标。构建时服务注册中心（例如企业 UDDI 目录）可能能够解决部分问题。

    示例：汽车工作订单

    汽车工作订单（Automotive Work Order）描述了一家汽车维修公司管理其顾客运营的流程。我们将通过这个领域中的问题来阐述 SOAD 的观点。

    工作订单代表汽车服务公司和顾客之间的约定，以进行一系列例行维修或应急维修，例如例行 50,000 英里服务，更换刹车片或轮胎，或者换油。

    业务场景（如 图 7所示）如下：

    当顾客打电话预约时创建工作订单。
    为每个计划的维修活动或操作创建一个独立的工作订单项，其中包括需要使用的零件、备件和劳务的详细情况。
    在安排预约之前确保所有必需的零件都有库存。
    需要为每个工作订单项安排具有适当的装备的维修间以及具备适当的条件的机器。
    计算估计的总成本，接着顾客认可该预约；或者方案终止，随即取消工作订单。
    在预约之前，立即在选定的维修间装配必需的零件、备件、工具和设备。
    当顾客到达时，进行计划的活动以及在检查交通工具时显得有必要的任何其他活动。
    记录所用的零件和备件的实际价值以及劳务。
    在完成所有的维修时计算总费用。
    创建发票并且将其交给顾客。


    图 7：工作订单的宏流示例 

    如果您将此作为一个独立的应用程序从头开始创建，您就可能创建一组如 图 8所示的类。


    图 8：工作订单的类图示例