4

我一直在搜索（主要是 google）来尝试找到可以用来识别 SOA 服务的功能责任的工具或方法。我的搜索并没有真正想出任何东西。

目前，我用于确定职能职责的方法是临时的，实际上只是直觉，例如

  • 所有与客户相关的功能都进入客户服务
  • 所有与支付相关的功能都进入支付服务
  • ETC

反思软件设计/架构领域中使用的其他方法：

  1. 面向对象分析具有类责任协作（CRC）模型的概念来决定类的责任。

  2. 据我了解，域驱动设计 (DDD) 具有有界上下文的概念，可以对域进行逻辑分区。

  3. 在传统的软件架构中：

问题： SOA 架构师有哪些工具/方法可以让他们确定服务的功能职责？

4

1 回答 1

3

您的方法和分析似乎合理，围绕它试图解决的业务问题保留服务功能。客户相关功能进入客户服务等。但是，您需要巩固决策过程并消除直觉方法。

您所指的是所谓的 SOA 设计时策略的一部分，它是称为 SOA 治理的更大主题的一部分。请记住，仅仅拥有一堆 Web 服务并不会使您的架构 SOA 而是基于服务，因此在进入 SOA 架构之前，您必须经历设置 SOA 治理的痛苦。请注意，我假设这不存在。

您的 SOA 治理策略将指定如何设计您的服务。围绕服务设计的典型 SOA 设计时策略可能看起来像这样。

可重用性设计。

当你设计一个服务时，如果这个服务可以被其他服务和消费者重用，那就太好了。

如果您查看 SOA 系统及其提供的所有服务，您可能会注意到服务提供不同级别的粒度。您可以拥有任何东西，从允许您修改实体的单个属性的服务到允许您申请贷款的服务。现在为什么这种粒度很重要？服务的粒度定义了重用它的难易程度。

细粒度服务通常比粗粒度服务更容易重用。以下是如何分解此粒度的示例：

  • 流程服务：流程服务是最粗粒度的服务。这些类型的服务最常向其消费者提供服务或产品。典型的流程服务示例类似于汽车销售。在这种情况下，销售系统需要更新，库存系统需要更新，并且此交易涉及更多系统。流程服务将调用其他服务来完成其任务。通常，当您在许多服务之间进行编排时，您正在处理一个流程服务

  • 业务服务：业务服务为系统提供单一、特定的业务功能。例如，使用汽车销售相关的发票和税务文件更新销售系统。

  • 技术服务：最细粒度的服务是技术服务。技术服务为其他服务提供一小部分特定功能。这方面的一个示例是更新地板上汽车库存的服务，即将数据库中的汽车标记为已售出，其他示例是发送电子邮件或调用遗留后端。

您还应该保留服务目录。此目录必须与服务及其功能保持同步，以消除服务重复。它还允许您确定必须在何处定义服务功能。

使用服务目录和设计时策略将允许您决定功能应该放在哪里。

我会推荐这本书，因为它涉及围绕 SOA 的整个管理。至于使用哪种正式的方法，我建议尝试它们并保留适合您的方法。请记住，让业务人员加入您的决策团队会有所帮助，因为他们了解业务，他们可能会让您深入了解功能应该在哪里。只需在您的 SOA 治理策略中将其正式化，并每 8-12 个月审查一次这些策略，以确保它们仍然相关并为您工作。

于 2014-01-07T22:21:21.270 回答