我一直在搜索（主要是谷歌）尝试查找工具或方法，我可以用它来确定SOA服务的功能责任。我的搜索并没有真正想出任何东西。
目前，我用来决定职能责任的方法是adhoc，实际上只是直觉，例如
反思软件设计/架构领域中使用的其他方法：
面向对象分析具有Class Responsibility Collaboration（CRC）模型的概念来决定类的责任。
根据我的理解，域驱动设计（DDD）具有bounded contexts概念，可以对域进行逻辑分区。
在传统的软件架构中：
问题：SOA架构师有哪些工具/方法可以让他们确定服务的职能？
答案 0 :(得分：3)
您的方法和分析似乎是合理的，保持服务功能围绕它试图解决的业务问题。与客户相关的功能可以用于客户服务等。但是，您需要巩固决策过程并消除直觉感受。
您所指的是SOA设计时策略，称为SOA治理这一更大主题的一部分。请记住，拥有大量Web服务并不会使您的架构SOA更加基于服务，因此在进入SOA架构之前，您必须经历设置SOA Governance的痛苦。请注意，我假设这不存在。
您的SOA治理策略将指定如何设计服务。典型的SOA设计时间策略可能与服务设计类似。
设计可重用性。
当您设计服务时，如果这项服务可能会很好 被其他服务和消费者重用。
如果你看一下SOA系统及其提供的所有服务，你可能会注意到服务提供了不同的级别 粒度。您可以从允许修改单个服务的服务中获得任何内容 实体的财产，允许您申请的服务 贷款。现在为什么这种粒度很重要？服务的粒度定义 它是多么容易被重用。
细粒度服务通常可以更容易地重复使用 粗粒度的服务。以下是如何分解这种粒度的示例：
流程服务：流程服务是最粗粒度的服务。这些种类 服务通常为消费者提供服务或产品。一个典型的流程服务示例就像销售汽车一样。在这 销售系统需要更新，库存系统需要 更新，此交易涉及更多系统。一个过程 服务将调用其他服务来完成其任务。通常，当您在许多服务之间进行编排时，您正在处理流程服务
商业服务：商业服务提供单一，特定的商业功能 对于一个系统。例如，使用关于汽车销售的发票和税务文档更新销售系统。
技术服务：最优质的服务是技术服务。一个技术 service为其他服务提供了一小段特定功能。一个例子 这将是一项更新地板上汽车库存的服务，即将数据库中的汽车标记为已售出的其他示例将是发送电子邮件，或称为传统后端。
您还应该保留服务目录。此目录必须与服务及其功能保持同步，以消除服务重复。它还允许您确定必须定义服务功能的位置。
使用服务目录和设计时间策略将允许您决定功能应该在哪里。
我建议this book因为它涉及围绕SOA的整个管理。至于使用哪种正式方法我会建议尝试它们并保留适合你的方法。请记住，让业务人员参与决策制定团队会有所帮助，因为他们了解业务，可能会让您深入了解功能应该在哪里。只需在您的SOA治理策略中将其正式化，并每8-12个月检查一次这些策略，以确保它们仍然相关并且正在为您工作。