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