（Web Services Description Language，WSDL）的多。因此，Web 服务策略（WS-Policy） 框架是一个重要的相关规范。
除了已经制定的良好体系结构可跟踪性原则之外，业务可跟踪性也是一个理想的品质：应该有可能将所有的运行时构件直接与非技术领域专家可以理解的语言联系起来。这对于直接在业务和服务层公开的抽象非常重要。Sarbanes-Oxley (SOX) 法案（请参阅来自 Astor 的文章）是需要这种业务可跟踪性的业务驱动程序的一个例子。
流程：中间相遇
在真实世界中，并没有全新的项目，必须始终考虑遗留系统（遗留系统是现有系统的同义词）。因此，需要中间相遇的方法，而不是单纯的自顶向下或自底向上的流程。
在设计取决于现有的 IT 环境而不是现在和将来的业务需要的情况下，自底向上的方法往往会导致不好的业务服务抽象。而自顶向下的方法可能会产生不足的非功能性需求特征，并且损害其他的体系结构品质因素（例如因域模型中缺乏标准化而导致的性能问题），另外，也会在服务和组件中产生不匹配的不良问题。
服务获取和知识代理
这是一个知识管理和生命周期问题：如何成功地准备好服务并且使其在概念化之后可以重用？
应该将重用看作是标识和定义服务最主要的推动标准之一。如果组件（或服务）不可能重用，就不无法将其作为服务进行部署。它可以连接到另一个与企业体系结构相关的服务，但是不能单独作为一个服务而存在。
然而，即使从开始就计划好了重用，还必须形式化服务获取流程。由多个使用者使用服务是明确的 SOA 设计目标。构建时服务注册中心（例如企业 UDDI 目录）可能能够解决部分问题。
示例：汽车工作订单
汽车工作订单（Automotive Work Order）描述了一家汽车维修公司管理其顾客运营的流程。我们将通过这个领域中的问题来阐述 SOAD 的观点。
工作订单代表汽车服务公司和顾客之间的约定，以进行一系列例行维修或应急维修，例如例行 50,000 英里服务，更换刹车片或轮胎，或者换油。
业务场景（如图 7 所示）如下：
当顾客打电话预约时创建工作订单。
为每个计划的维修活动或操作创建一个独立的工作订单项，其中包括需要使用的零件、备件和劳务的详细情况。
在安排预约之前确保所有必需的零件都有库存。
需要为每个工作订单项安排具有适当的装备的维修间以及具备适当的条件的机器。
计算估计的总成本，接着顾客认可该预约；或者方案终止，随即取消工作订单。
在预约之前，立即在选定的维修间装配必需的零件、备件、工具和设备。
当顾客到达时，进行计划的活动以及在检查交通工具时显得有必要的任何其他活动。
记录所用的零件和备件的实际价值以及劳务。
在完成所有的维修时计算总费用。
创建发票并且将其交给顾客。
图 7. 工作订单的宏流示例
文章来源于领测软件测试网 https://www.ltesting.net/
