如何确定 SOA 服务的功能职责？

Question

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

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

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

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

1. 面向对象分析具有Class Responsibility Collaboration (CRC) 模型的概念来决定类的职责。

2. 据我了解，域驱动设计 (DDD) 有 bounded contexts 的概念来对域进行逻辑分区。

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

   • Process of Software Architecting 这本书有一种与 CRC 类似的方法，用于识别软件组件及其职责。
   • Architecture Based Design 流程包含划分职责信息功能区域的步骤。

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

Answer 1

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

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

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

设计可重用性。

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

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

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

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

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

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

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

使用服务目录和设计时策略可以让您决定功能的位置。

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