Chr*_*now 5 architecture soa domain-driven-design crc-cards
我一直在搜索（主要是 google）来尝试查找可用于识别 SOA 服务的功能职责的工具或方法。我的搜索并没有真正得出任何结果。
目前，我用来决定职能职责的方法是临时的，实际上只是直觉，例如
Reflecting on other approaches used in the software design/architecture world:
Object Oriented Analysis has the concept of Class Responsibility Collaboration (CRC) models to decide the responsibility of classes.
From what I understand, Domain Driven Design (DDD) has the concept of bounded contexts to logically partition a domain.
In traditional software architecting:
Question: What tools/methodologies does the SOA architect have that allow them to determine the functional responsibilities of a service?
您的方法和分析似乎合理地围绕其试图解决的业务问题保留服务功能。与客户相关的功能涉及客户服务等。但是，您需要巩固您的决策过程并消除直觉方法。
\n\n您所指的称为 SOA 设计时策略，是称为 SOA 治理的更大主题的一部分。请记住，仅仅拥有一堆 Web 服务并不会使您的架构变得 SOA 而是基于服务，因此在进入 SOA 架构之前，您必须经历设置 SOA 治理的痛苦。请注意，我假设这并不到位。
\n\n您的 SOA 治理策略将指定如何设计您的服务。典型的 SOA 设计时策略可能类似于服务设计。
\n\n可重用性设计。
\n\n当您设计一项服务时，如果该服务可以被其他服务和使用者重用，那就太好了。
\n\n如果您查看 SOA 系统及其提供的所有服务，\xe2\x80\x99 可能会注意到服务提供不同级别的粒度。您可以拥有任何服务，从允许您修改实体的单个属性的服务到允许您申请贷款的服务。\n 为什么这个粒度很重要？服务的粒度定义\n重用它的难易程度。
\n\n细粒度的服务通常比粗粒度的服务更容易重用。\n 以下是如何分解这种粒度的示例：
\n\n流程服务：流程服务是最粗粒度的服务。此类服务通常向消费者提供服务或产品。典型的流程服务示例类似于汽车销售。在这种情况下，销售系统需要更新，库存系统需要更新，并且此事务涉及更多系统。进程服务将调用其他服务来完成其任务。通常，当您在许多服务之间进行编排时，您正在处理流程服务
业务服务：业务服务为系统提供单一、特定的业务功能。例如，使用汽车销售的发票和税务文件更新销售系统。
技术服务：最细粒度的服务是技术服务。技术服务为其他服务提供一小部分特定功能。一个示例\n是更新地板上汽车库存的服务，即将数据库中的汽车标记为已售出，其他示例是发送电子邮件或调用旧后端。
您还应该保留一份服务目录。该目录必须与服务及其功能保持同步，以消除服务重复。它还允许您确定必须在何处定义服务功能。
\n\n使用服务目录和设计时策略将允许您决定功能应该位于何处。
\n\n我推荐这本书，因为它涉及 SOA 的整个管理。至于使用哪种正式方法，我建议尝试并保留适合您的方法。请记住，让业务人员加入您的决策团队会有所帮助，因为他们了解业务，他们可能会让您深入了解功能应该在哪里。只需在您的 SOA 治理策略中将其正式化，并每 8-12 个月检查一次这些策略，以确保它们仍然相关且适合您。
\n