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

Question

我一直在搜索(主要是谷歌)来尝试查找工具或方法，我可以使用这些工具或方法来确定 SOA 服务的功能职责。我的搜索并没有真正想出什么。

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

所有与客户相关的功能都进入客户服务

所有与支付相关的功能都包含在支付服务中

等

反射(reflection)软件设计/架构世界中使用的其他方法:

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

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

在传统的软件架构中:

书Process of Software Architecting具有与 CRC 类似的方法，用于识别软件组件及其职责。

Architecture Based Design流程具有划分职责信息功能区域的步骤。

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

Answer 1

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

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

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

可重用性设计。

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

如果您查看 SOA 系统及其提供的所有服务，您可能会注意到服务提供不同的级别
的粒度。您可以从允许您修改单个服务的服务中获得任何内容
实体的属性(property)对允许您申请的服务的
贷款。现在为什么这个粒度很重要？服务的粒度定义
它可以很容易地重复使用。

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

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

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

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

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

使用服务目录和设计时策略将允许您决定功能应该位于何处。

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