- 业务中台设计方法
基于标准的业务中台服务化设计流程结合营销的业务特性和项目特性，形成系统业务中台服务化设计总体流程方法：
按照系统业务中台的建设特性，整体业务中台服务化设计实施过程分为服务中心规划、服务识别、服务设计、服务实现、服务治理。及其涉及的业务相关提交件的输入要求、业务中台相关提交件的输出、设计过程的一些列标准、模板和规范。
在服务中心规划阶段的主要工作是基于业务领域模型的输入根据服务中心规划方法和决策流程及指标确定系统的服务中心，根据服务中心确定系统的业务中台架构。
在服务识别阶段，依赖业务需求分析产出的四级或五级流程、业务时序图、业务规则、业务功能等作为服务识别的输入，再根据各种需求输入对应的服务梳理方法梳理出备选服务。针对备选服务依据服务中心规划做筛选、聚合、归类形成系统的服务模型，同时根据服务的非功能需求产出业务中台技术能力支撑。
在服务设计阶段，根据服务识别阶段产出的服务模型，设计对外暴露的服务接口和操作，设计各个服务中心的数据模型，设计服务中心的部署模型。
在服务实现阶段，根据服务设计阶段的产出，依据代码开发规范、微服务开发最佳实践，进行服务接口的代码业务逻辑实现。及开发完成后的服务单元测试、服务集成测试、服务非功能测试等，及服务部署上线。
在服务治理阶段，针对服务的持续运营，收集及反馈服务实际运行信息，促进服务的持续迭代，持续的满足和促进业务创新，真正达到以客户为中心服务好客户的核心主旨。
3.1. 服务中心规划
根据系统业务中台的建设特性，服务中心规划分为几个阶段：业务领域建模阶段、服务中心推导规划阶段、服务中心评审阶段、业务中台架构形成阶段。
在业务领域建模阶段由业务专家和业务架构师使用领域分析方法来分析现有和未来的业务，根据业务所涵盖的全量用户用例模型分析抽象其中的业务对象和业务实体及其之间的关系，从中推导规划出业务领域模型作为下一阶段服务中心规划的业务输入。
在服务规划阶段由中台架构师与业务架构师根据业务领域模型推导出的服务中心规划蓝图。
在中心评审阶段由中台管控组主持审核服务中心规划，根据预先指定的服务中心评审标准，确定中心规划的合理性和中心实施计划和资源安排。
最终根据服务中心规划审批的意见和结果，形成系统的业务中台架构，作为后续服务梳理的范围和依据。
3.2. 服务识别
服务识别总体流程：
业务专家、业务架构师分析产出的业务四、五级流程，业务时序图，业务详细功能/规则说明作为服务梳理的业务输入。
业务架构师和中台架构师一起根据业务输入材料的不同，根据服务业务流程分析方法、服务时序分析方法、服务功能分析方法进行服务的梳理，产出初步的营销服务模型。
中台架构师根据初步的营销服务模型，进行抽象归纳。相同业务能力的进行合并；类似业务能力的进行归集形成服务操作，并抽象服务操作的输入输出，尽可能的共用一个服务操作；遵守可以被重用（Be Reusabled），可以被组合（Be Composabled），描述和实现分离（Separation Implementation from Description），自治的（Autonomous），无状态的（Stateless）。完成营销服务/操作模型定义，提交中台管控组审核。
中台管控组根据服务评测方法对营销服务模型进行评审，通过后的形成确定的营销服务模型指导后续服务设计，为通过评审的重新梳理抽象归类。
服务化–是将企业资源以业务能力的形式组织起来，通过一定的技术架构对这些业务能力进行封装形成易于消费的服务，从而实现业务能力粒度上的使用、组装、维护和管理，来灵活迅捷构筑实现特定业务目的的企业应用。服务化降低了新业务应用的建设成本周期和风险，并使得大规模分布式架构的采用成为可能：
1. 业务能力的提供和消费方式标准化；
2. 业务能力之间的组装更灵活；
3. 应用实现更关注于业务能力的使用。
使用不再限于单一系统应用内部，跨系统、跨部署的业务能力使用不再是障碍。
服务识别的主要方法是业务解析和利旧分析，识别出无状态的高内聚松耦合的业务能力形成服务目录。
业务解析对预设的业务目标和业务模型，从顶级业务流开始，自顶向下，从流程、数据和规则三个方面层层解析。
输入：项目业务目标、业务流程模型、业务域定义、系统上下文。
利旧分析对需要全部或部分重用的，要接入改造甚至重新建设的内外应用和系统，针对其已有设计自底向上逐步归纳。
输入：系统上下文、已有系统的流程定义、接口规范、数据模型、业务规则
服务识别是一个渐进过程，将业务能力梳理成按业务域组织的有层次的服务目录。在此过程中会逐步调整业务流程定义、业务规则、数据模型（主要在粗粒度的概念模型、逻辑模型层次上），甚至业务域定义和系统上下文都可能做调整，所有这些调整都是：
以更有效地支撑企业业务目标和愿景（如简化业务流程、提高执行力等）为根本原则；
以消除冗余（识别共同活动）和增强灵活性（识别易变活动）为基本方法。
以上述过程识别出的服务，还只是备选服务，不过已经可以初步满足服务化的以下原则：
无状态原则– 先从业务意义业务边界上保证这一点，以支持可伸缩高可用部署，会在服务设计阶段进一步加强。
高内聚松耦合– 以业务能力为基本粒度，业务含义和边界清晰完整，更容易精准地描述和定义服务。
业务契约先行– 清晰的服务功能提供了初步的服务提供者和消费者间的契约基础，会在服务设计阶段进一步加强。
业务归属清晰– 按业务域的层次组织方式，易于垂直划分方便组织开发和维护，且便于以节点为单位分析调整。
系统层次清晰– 按业务域的层次组织方式以及服务分类，对横向的系统层次架构的设计考量提供了强力支持。
3.3. 服务设计
服务设计以服务识别出的服务模型为基础，针对服务粒度、依赖组合关系做合理调整（更新服务目录和服务关联）；并对服务接口（输入输出异常）、服务应用分组、以及部署方式，以契约先行和更好地支持可伸缩高可用（如无状态原则）为目标做进一步的设计，同时在性能、管控、安全等非功能性需求方面对接下来的服务实现阶段提出明确的要求（服务定义）。
在这个设计服务模型的过程中会逐步明确完善系统整体架构，包括:
架构主题决策 例如有哪些不同的服务暴露、交互的场景、以及在安全上的考虑等。
系统组件模型 例如有哪些应用、各提供什么服务。
系统部署模型 例如应用和数据的部署位置、部署方式、交互方式等。
服务设计阶段，针对服务模型（服务目录+服务关联+服务定义）的设计，自上而下、由粗到细，有以下一些参考原则：
- 管理原则
业务管理垂直化 – 以垂直业务划分开发维护团队，澄清跨团队服务消费需求并定义服务契约，方便背对背模式。
垂直化拆分以3至8人的开发维护团队为最小理想粒度。
数据归属单一化 – 主数据主规则（可写）存储归属于单一业务域，跨域数据规则读写必须通过所属域的服务。
系统组织层次化 – 划分服务的系统逻辑层次，大量重用的服务，尽可能下沉，对服务依赖做逻辑层次级上的限制。
例如数据服务，在其上设置核心业务层（共享业务服务和规则服务）和再上层的系统业务层（组合、定制等）。
定义层次规则，上层可调用同层或下层服务，禁止下层调用上层服务，禁止重要服务依赖非重要服务。
- 契约原则
合适粒度原则 – 平衡可维护性与易用性。可提供普适的大粒度业务逻辑片段，根据需求增加精细化的服务接口。
强描述性原则 – 服务名（名词）以及方法（动词）意义明确，表意精准，服务模式明确（同步、异步）。
内聚完整原则 – 从服务消费者的角度出发，考察服务提供业务能力的完整性，即功能组合的自洽。
语义接口原则 – 接口信息使用语义化封装，内外隔离，接口信息对象独立于服务内部的实现信息对象定义。
接口普适原则 – 接口信息基本属性使用跨语言的基本类型（字符串、日期、数值等）。
扩展兼容原则 – 在保证易用性的前提下，尽可能考虑未来扩展，避免未来频繁更改接口。
实现指导
超时保护 – 要提供超时时间控制。
快速失败 – Fast Fail，只要发生错误，立刻返回，避免服务调用时间过长。
结果可预期 – 任何服务的调用结果一定是三种之一：成功、失败、未知，如果是未知需要再次检查。
服务无状态 – 在实现设计上保证服务无状态，避免让服务维护跨服务的会话上下文。
可重入幂等 – 在实现设计上保证服务操作的幂等效果。
乱序可容忍 – 分布式架构会使任务、数据被处理的顺序可能不同于其产生的顺序，需要在实现设计上消除乱序对业务一致性的影响，要么让处理对顺序不敏感，要么以牺牲性能可扩展性为代价，强制实现处理的顺序性。
3.4.服务实现
根据服务设计确定的服务模型的服务目录、服务关联、服务定义，并且在对系统整体架构的逐步完善中明确了这些服务的分组分类，以及不同的服务暴露、交互场景等，已经确定了该服务所采用的服务化框架实现的选型确定。开始真正“实现”服务模型里面的服务：
确定服务实现技术规范
涉及一系列的技术架构主题的分析、选型之后得到的通用和特例决策。
确定服务化框架
用什么产品来封装业务能力的实现，形成服务。服务化框架需要满足以下要求：
1、统一的服务发布、发现、调用方式
通常希望框架能支持在服务部署后可以自动注册和发布服务，可通过一致的方式获得服务的元数据、状态和使用资源信息等。
提供通用的其它方式（如HTTP转义）消费服务，以便用第三方产品做功能集成测试。
2、高性能、高可用、可线性扩展的调用能力，强大的服务管理支持 （鉴授权、流控、路由、追踪等）
确定对其他依赖服务和系统的调用、集成方式 如同步异步，批处理，消息、文件传输，事务管理方式等，特别地，其中常用的消息模式具有两大作用：服务间性能供需弹性解耦 – 削峰填谷；服务间业务能力深度解耦 – 消息驱动。
而事务管理则需要在扩展性和方便性上平衡考量，除非万不得已，在分布式事务处理中不使用强一致策略，而采用其他模式，例如：1) 努力送达（消息驱动不断重试）；2) 补偿模式（业务显式回滚 或 业务状态机设计等）来保证最终一致。
确定实现业务能力依赖的技术产品 如使用什么规则、搜索、消息、缓存引擎，工作流和数据持久化框架等。
编写、集成、组装、测试，形成应用部署交付件 要求之前服务设计阶段提出的实现指导原则能够切实落实。
部署服务 要求服务应用能够便捷甚至自动地适应不同的部署目标环境（如日常、测试、预发、线上）之间的切换。
3.5.服务治理
治理意指政策或策略的制定，管理则是在执行上落实治理政策和策略。这里所说的服务治理是指为了协调服务提供者和服务消费者，使服务化体系能够顺畅运转而制定的指导原则，以及执行这些原则所需要的技术手段。
服务演进其实是服务治理的一部分，这里单拿出来以强调在服务生命周期中的阶段性问题，即服务该如何更新以及该如何控制管理更新对已有服务消费者的影响。在之前服务治理中提到的强弱依赖和灰度控制都与此相关。服务被消费后也会需要更新，这些更新可能是因为要加入新的功能，或者要修复问题和错误，或者是从易用性上要做改进，或者从业务耦合性和完整性上要做合并拆分，也可能是单纯因为服务本身代表的业务能力发生了变化，例如规则、流程变化等。这些变化，有的并不会影响到已有服务消费者的继续使用，有的却要求已有服务消费者做改造。
