业务和流程驱动的SOA服务识别方法总结

　　今天整理和分享下流程驱动的SOA服务识别方法，该方法在传统SOA架构规划咨询中应用比较多，对于当前的微服务架构规划咨询仍然可以参考借鉴。服务识别整体流程说明
　　服务识别和服务需求分析的主要工作是基于SOA的需求分析方法论，以流程和业务驱动IT的指导思想，对业务系统进行业务建模，用例建模和业务实体建模，形成企业级需求和业务功能清单，作为后续服务识别的输入。
　　对于服务需求，以流程分析为基础，通过流程的逐层分解，细化出关键的业务活动，将流程活动识别为业务用例，并对业务用例进行建模。用例建模本身可以作为业务系统功能开发的需求规格说明书，同时对用例分析和功能操作的识别形成业务域-》流程分解-》用例-》业务操作的分解过程，用于后续服务的识别。
　　在整个分析过程中，流程的关键活动或业务用例的操作都会涉及到业务实体对象，因此需要对业务实体对象进行单独建模，分析实体对象的关键属性和对象间关系，同时分析实体对象和业务操作间的U/C矩阵，作为后续公用服务提取的基础。
　　服务识别开始于需求分析，终止于识别出的候选服务列表。为了有效的实施SOA工程，应用不能孤立于其他应用而独立开发。SOA的应用应该可以共享服务，这些服务不单单属于某个独立的应用，并且有自己的生命周期，能够被独立的管理。在SOA工程中，为了有效的管理需求，各个项目必须知道其他已经存在的项目、正在开发的项目以及未来将要开发的项目需求。所以，与SOA服务相关的需求应该在企业级层面管理。
　　对于服务本身可以分为业务服务，数据服务，技术服务等。从上图也可以看到通过业务流程分析和业务架构梳理来识别业务服务；通过数据架构和数据建模来分析和识别数据服务；通过技术架构分析来识别关键的技术服务能力。
　　候选服务是被识别出用于系统重用的业务功能。一个候选服务不一定一对一的对应到实际交付的服务，比如，在分析阶段，一个粗粒度的服务可能对应到需求中两个或两个以上的初始候选服务。另一方面，服务识别并不是简单的识别出候选服务，也包括了一系列的校验和评估。服务识别整体方法
　　对于服务识别的方法，在前面很多文章都已经讲到过，对于SOA实施中服务识别是相关重要的一个环节，如何基于业务驱动IT的思路，识别出真正粗粒度，高度自治，可复用的服务是后期服务治理管控能否顺利的一个关键。否则SOA建设到后期很容易就变成一个数据集成平台，而非是服务共享平台。要知道服务的本质还是接口和交互，因此对于服务的识别总体来说两种方法：自顶朝下：基于业务流程分析入手，分析跨系统业务流程交互，识别出集成点和接口点，再转化为服务 自底朝上：基于当前遗留系统已有的系统间接口情况，分析接口对应的业务场景，再进行接口转服务
　　可以看到不论是哪种方法，这里面都有两个重点，其一是必须要明确的清楚每一个服务的业务含义，对应的业务场景和业务交互点在哪里？其次就是需要做接口转服务这个关键动作。
　　1. 自顶朝下的服务识别
　　如果各个业务系统之间没有业务和数据的交互，那么跟根本不应该存在任何的接口或服务。而对于服务的存在原因主要还是我们的端到端业务流程往往是跨了多个业务系统的交互才能实现的，而这些跨业务系统的交互点要么进行业务规则的校验，要么进行关键业务数据和单据的传递。
　　这些交互点和集成点都是潜在的接口服务识别点，通过这种方式识别出来的服务我们就很清楚服务对应的业务流程和场景。比如采购系统和ERP之间有一个采购订单导入的接口服务，我们就很清楚整个供应链流程中，采购订单的创建和生效是在采购系统里面，但是基于采购订单的采购接收和入库是在ERP系统，因此需要将采购订单同步到ERP系统中。
　　这种跨系统流程分析基本会把横向的所有关键接口全部梳理出来，但是容易遗漏掉纵向的一些基础数据共享接口，距离来说我们在拟制采购订单的时候，是需要输入和选择项目信息，选择对应的库存组织信息的。而这些基础数据需要从项目管理系统和ERP系统中同步过来。但是在流程图中往往只会有采购订单创建节点，因此容易遗漏这些基础数据共享接口。
　　还有就是某一个业务功能在实现过程中，可能涉及到调用外部的业务规则和逻辑，这种交互点也容易遗漏需要特别注意。举例来说，采购订单在创建完成的时候并提交的时候需要检查预算是否足够，而这个检查规则逻辑是预算管理系统实现的，因此在这里也存在采购系统和预算系统间的业务接口和服务。
　　2. 自底朝上的服务识别
　　特别遗留系统环境进行SOA架构改造和服务接入的时候，我们要意识到必须要将遗留系统间的当前已有接口全部分析和梳理清楚。因为既然当前遗留系统能够正常运作，也能完成跨系统的业务交互，那么原来的接口从面上是完全能够覆盖业务需求的，我们唯一要考虑的是接口本身的定义和设计是否合理的问题。
　　当整理出完整的接口清单后，我们要做的就是搞清楚每一个接口对应的业务场景究竟是如何的？基于这种反向思路我们只关系和接口相关的业务交互场景，而不是关注全部业务流程。搞清楚了具体的业务场景后，接着要做的重点工作就是对接口进行评估，接口的评估主要包括了如下内容：a) 接口当前使用频度如何？是实时还是定时同步？同步频率能否满足业务的要求？ b) 接口传递的数据量如何？当前在数据传递的时候有无性能问题？ c) 接口本身的实现方法是如何的？比如Dblink，存储过程，WS接口，还是直接原始的JDBC接口等。 d) 接口本身的复用度如何？相关类似的接口有哪些？相互之间有哪些差异？
　　做了接口评估最主要的仍然是要考虑如何进行接口去重和接口合并，对于接口转服务的方法，我前面有专门一篇文章再谈，在这里就不再展开。
　　本身相互独立的两个业务系统，比如A系统和B系统，按道理两个系统应该完全独立，包括数据库，中间件，应用部署包等。两个系统之间只能通过标准的接口进行业务和数据的交互。但是实际在项目实施中发现一种普遍存在的现象，即A系统将自己的数据库账户完全开放为B系统，而B系统在拿到数据库连接串信息后，通过自己编码实现完全可以对数据库A中的数据库表进行各种任意的CRUD操作。
　　在这种情况下可以看到，A和B两个系统之间已经完全耦合在一起，这个时候A系统要做数据库层面的迁移和数据库表结构的变更往往全部会影响到B系统。如果要把这些接口点找到，必须要把B系统中的所有代码进行遍历查找和分析，往往才能够找到具体的接口点有哪些。这些不规范的使用方式都对后续的SOA服务改造和迁移造成相对重大的影响。业务建模
　　业务建模包括了业务调研，业务流程分析，全局用例建模和全局数据建模几个关键内容。其中核心仍然是基于业务流程驱动，基于流程分析来识别关键的业务用例和业务对象。
　　业务调研
　　该部分包括业务需求调研，包括业务流程或问题产生的背景介绍，具体的业务需求收集和分类。现有的业务流程现状，业务需求所在的具体业务域，涉及到的岗位角色人员信息等。业务调研包括了业务流程，业务数据，业务系统三个方面的内容，业务调研内容具体输出为业务调研文档。
　　业务调研完成后应该输出完整的业务流程调研报告，其中也包括了对业务系统间交互接口的调研和现状梳理。
　　流程分析
　　流程分析需遵循端到端流程分析的思路，对流程进行二级，或三级分解。流程分析前可以先进行主题域分析，绘制上下文关系图，通过上下文关系图来进一步识别关键业务流程。具体参考流程分析指导书。
　　通过上下文关系图对主题域进行分析后，可以得到主题域中所包含的业务事件，而这些业务事件就是业务流程的起点。流程分析时，需要注意流程的目标性、内在性、整体性、动态性、层次性、结构性这六大特性，流程是需求分析的重要内容，流程图对于和用户确认需求以及向开发团队传递需求都是非常重要的。可以选择使用UML规范中的活动图或商业建模标准中所推荐的跨职能流程图对流程建模。
　　通过流程分析可以进一步明确流程的的关键业务活动，每个业务活动的输入，输出，涉及的岗位角色，传递的业务数据等关键内容。具体流程分析输出包括：业务系统所涉及的端到端业务流程图业务域的业务流程分解图针对业务流程图进行的详细业务流程活动和输入、输出描述
　　全局用例建模
　　根据业务域划分和业务流程分析，进行用例的识别，流程中清晰地表达了角色所要执行的业务活动，这正是用例的内容，用例即用户使用系统完成业务活动的场景在将业务活动及报表转换为用例后，使用UML中的用例图对用例建模，用例图不但可以表达出用户是如何使用系统的，还可以表达出用户与用户之间的关系，用例与用例之间的关系。
　　对于流程图转换到用例的具体方法，可以参考需求分析指导书中的详细说明和转换原则。对于业务用例分析和建模基础，请参考UML相关文档。
　　全局数据建模
　　本部分主要是根据流程分析和用例建模，抽取流程和用例中的关键业务实体对象进行数据建模分析。全局数据建模只需要分析出关键的业务实体，实体描述和实体之间的关系即可，在业务实体建模环节讲进一步对该部分内容进行细化分析。
　　全局数据建模需要输出数据概念模型，数据实体对象清单和实体描述信息。用例建模
　　用例建模
　　用例建模首先是流程建模中的关键业务活动会转化为用例，这在全局用例建模中会进行分析。从流程图中转换用例时，先基于流程图分析流程图中的职能带区(泳道)哪一些是不直接使用系统，将其排除，将余下的职能带区(泳道)转为角色，将流程图中的业务活动及判断转换为用例，决定活动是否要转换为用例的标准是它是否属于系统范畴，而决定判断是否要转换为用例的标准是它是否独立。
　　用例建模需要参考用例编写标准模板进行用例的编写，针对每一个用例需要填写的内容主要包括如下：用例的编号，名称，级别等信息。
　　用例执行的上下文背景介绍
　　用例执行的前置条件，后置条件，最小保证
　　用例执行的基本流
　　用例执行的扩展流
　　业务规则信息
　　假设和约束信息
　　其它备注或说明信息
　　业务操作分析
　　在用例建模的过程中，用例本身即是一个实现业务价值的交互业务活动集合。因此可以对用例进一步分析，识别更细粒度的业务活动和操作，这些业务活动或操作可以从基本流，扩展流和业务规则中寻找。业务操作分析要求如下：业务操作即业务活动中的业务任务，有明确的业务含义
　　业务操作本身是可复用的业务单位
　　业务操作本身采用动宾结构进行描述
　　 业务操作本身具有高内聚，松耦合性的自治性数据建模
　　业务实体分析
　　用例模型只是对用户如何使用系统的业务场景进行建模，如果要构建系统，还需要对系统的框架进行建模，即要弄清楚目标系统所要管理的＂物＂：业务实体，并弄清楚这些业务实体间的关系。
　　在对业务实体建模时，一般是使用＂名词动词法＂识别出业务实体，并逐步确定实体间的关联关系及其属性。
　　对业务实体建模选择使用UML规范中的类图或实体图作为模型，类图/实体图中的一个类/实体表达一个业务实体，类/实体的属性用于对业实体的属性建模，而它们之间的关系则可以用来对业务实体间的关联关系建模。对于比较复杂的业务实体，还可以采用UML规范中的状态图对其建模，可以表达出业务实体的状态切换与触发事件的关系。
　　业务实体分析中需要对识别的业务实体详细描述业务实体的数据字典信息，包括业务实体中各个数据项的类别，长度，完整性规则，业务用途等相关信息。
　　实体使用U/C矩阵分析
　　实体使用分析主要包括业务实体跨系统使用情况分析和业务实体系统内使用情况分析两方面的内容。
　　跨系统使用情况分析，主要是为公共数据服务的提取做准备，在该分析矩阵中需要列出业务系统产生的关键业务实体，分析这些业务实体在MSS域相关业务系统中的CRUD情况，作为后续数据服务识别的一个输入。
　　业务实体系统内使用分析，主要分析系统内关键业务实体和业务用例之间的对应关系，找寻系统内可复用的业务操作，为系统内服务识别做准备。服务识别
　　数据服务识别
　　数据服务为以实现业务系统底层数据集成为目的，以业务实体为核心的数据对象传输为主的SOA服务。数据服务没有明确的业务规则和含义。一般服务消费方在消费数据服务后都需要将数据同步到本地数据表，再根据业务系统自身需要对数据服务进行相关业务规则的封装和实现。
　　01 业务实体确认
　　在业务建模和数据建模阶段，已经对业务实体进行了分析，包括业务实体的类型，业务实体和业务功能的U/C矩阵分析等。业务实体是识别数据服务的基础，因此需要对业务建模阶段识别的业务实体进行确认。业务实体完全是业务视角的业务对象，而不是数据库设计中的数据库表，如采购订单业务实体可能涉多层结构和多张数据库表，但是在此处的分析只需要考虑采购订单业务实体对象。
　　02 服务重用性分析
　　在业务建模构建的U/C矩阵的基础上，可以从两个层面分析服务的重用性。一个是跨业务系统的服务重用性，一个是在一个业务应用内部业务模块间的服务可重用性。当一个业务主数据或一个核心业务单据需要跨多个业务系统或业务模块使用的时候，则该业务实体识别为数据服务是可重用的。
　　03 服务实现方法分析
　　在服务实现的时候，一方面是考虑服务的可重用性，一方面是考虑业务敏捷要求。对于数据类服务一般可以实现为查询类数据服务，也可以实现为导入类数据服务。当业务数据的业务敏捷性和时效性要求高时候，优先考虑实现为导入和分发类服务满足业务敏捷性的要求。
　　04 服务大数据量传输分析
　　对于底层数据集成类服务，可能涉及到大数据量传输，这种数据对实时性要求不高，但是任何一个批次传输可能都在10万级以上的数据量。对于这种情况要单独进行分析，分析服务数据量，调用频度，数据同步机制等。对于大数据量传输在识别为数据服务的时候可以考虑ODI服务，JMS消息，数据分页等多种方式来实现。
　　业务服务识别
　　业务服务是有明确业务含义的，含具体业务规则和逻辑的，实现一个有价值的业务活动的一系列业务操作的组合。业务服务具有明显的高业务内聚性，粗粒度特征。
　　01 业务组件确认
　　业务组件是实现多个业务功能的，高内聚松耦合的业务功能模块单元。业务组件是可以进行独立需求分析，设计，开发，测试和部署的组件管理单元。
　　对于一个完整的业务系统或业务流程是通过业务组件的交互和协同来完成。业务组件之间的交互则通过标准的SOA服务方式进行。即业务组件中包含了技术组件和服务组件，其中服务组件暴露业务服务。
　　业务组件和服务的详细关系如下：1.	对SOA服务进行分析，可以从服务中发现组件。对服务进行组合、功能及UI界面封装可以形成新的组件，所以组件可以调用一个或多个SOA服务，成为服务的消费者； 2.	组件按照SOA服务识别规范，抽取服务，可以成为服务的提供者。
　　02 业务服务识别
　　对于业务服务识别分为两个层面的内容。其一是为了实现跨业务组件的业务流程分析出来的业务组件之间的业务交互。其二是在用例建模阶段我们对业务操作进行了详细分析，对于这些分析整理出业务操作清单，对于业务操作清单中的可重用的业务操作识别为关键的业务服务。具体识别步骤为：1.	根据业务流程或业务用例，绘制相应的跨业务组件协作的业务交互图。 2.	对所有的业务交互点识别为潜在的业务服务。 3.	对业务操作活动列表进行分析，将可重用的业务操作识别为潜在的业务服务。
　　UI组件服务识别
　　UI组件是可以完成独立的业务功能的小业务应用。UI组件可以独立进行需求分析，设计，打包，部署和运行。UI组件是一种页面内嵌的方式在多个业务系统中运行，因此在UI组件复用的情况下，基本不需要进行底层的数据集成和同步操作，可以更好的保证数据的一致性和时效性。
　　对于UI组件的识别主要分为两个层面进行：
　　从顶向下识别：对于业务系统在构建中的业务系统和系统需求进行分析，在系统需求阶段会进行详细的功能需求描述和UI界面描述。可以针对这些需求文档分析重复的业务功能界面，将其识别为潜在的UI组件服务。
　　从下向上识别：该方法是首先对业务系统中的平台化功能模块进行抽象，如工作流管理，系统管理，公共技术服务等都是可以进行平台化的组件功能模块。
　　对于平台化的组件功能模块需要和业务系统进行界面层的交互，因此对于这些界面层交互可以由平台层提供UI组件服务内嵌到各个业务系统中使用。
　　技术服务识别
　　技术服务是和业务无关的，提供某种技术能力的服务。技术服务一般包括消息，安全，日志，会话，规则，异常，数据库管理等多个方面的内容。对于技术服务的识别仍然是包括了两个层面：
　　从顶向下识别：在业务建模和业务系统需求分析过程中，需要关注业务系统非功能性需求的描述，这些非功能需求包括了异常，日志，安全，性能，可靠性，高可用性，可扩展性，大数据量处理等多个方面的内容。对于这些非功能需求如果有多个业务系统或模块提出，则可以考虑抽象识别为公有的技术服务。
　　从下向上识别：该方法是从平台层面进行考虑，企业在业务系统建设过程中一般会分为产品层和平台层，对于平台层又包括了产品平台和技术平台。
　　在进行平台化功能构建的过程中，平台层需要朝产品层提供能力，这些能力的提供都可以考虑以技术服务的方式统一提供。以实现产品层和平台层的集成。
　　流程服务识别
　　对于流程服务的识别，仍然是以前期输出的端到端流程梳理和分析入手，以核心业务对象传递为基础，梳理识别流程片段，将流程服务转变为子流程和服务组合。流程服务的识别需要考虑服务的粒度，应以识别出来的流程片段本身也具备一定的服务价值为重要的衡量标准。