分布式|首发丨阿里云刘伟光：3.5万字拆解「核心系统转型」，核心从业者怎样寻得「出路」？(13)

文章插图

1.业务建模包括业务流程建模和业务对象建模：

业务流程建模：通过对业务流程现状分析，结合目标核心系统建设能力要求，参考行业建模成果，形成结构化的业务流程模型；
业务对象建模：基于信息模型资产，结合对业务流程提取的业务实体，进一步分析实体间关系，获得业务对象模型和业务行为模型。

2.技术建模是为了对业务模型进行落地实现，把上述业务模型转换为技术模型。通过技术建模，实现三个模型的转换：

业务流程模型到服务流程组合的转换；
业务对象模型到逻辑/物理数据模型的转化；
对象行为模型到API接口/原子服务的转换。

3.3.1.2建模平台
建模工具是支持业务领域建模的平台，包括对领域模型、数据模型、中台能力模型等的管理，提升建模设计效率并有效沉淀最佳实践。

在建模平台中，业务模型包含领域架构、业务模型、业务流程、交易模型、信息模型五层，五层概念逐层缩小：
领域架构作为系统的整体架构，包含系统中所有的业务模型，把系统中的业务模型按架构图的方式编排起来；
业务模型是由业务流程组成，是多条业务流程的集合；
业务流程串联交易模型，形成业务流程图；
交易模型中定义交易行为、交易的属性及交易行为的输入输出；
信息模型主用于定义九大信息要素：参与者、产品、合约、账户、事件、条件、地理位置、资源项、渠道，理论上任何交易模型都是由九大信息要素构成，在不能满足时也支持添加新的信息要素。

在建模平台中，技术模型包含：微服务模型、流程模型、实体模型、数据模型。

微服务模型是利用云原生特性，把业务流程中的步骤进行聚类分析，获得相应的微服务模型；
流程模型承接业务建模中的业务流程，通过对业务流程中的功能进行细化分析，获得实现业务功能的一个或多个具体接口，明确每个接口的输入输出字段，分析出实现业务功能所需的实体及实体间关系，获得实体模型；
需要持久化的实体模型，按数据库设计的相关要求转换为数据模型，通常情况下实体模型与数据模型是一对一或一对多关系。

通过上述步骤，最终得到技术模型中的微服务模型、流程模型、实体模型和数据模型。
3.3.2应用架构集成
应用架构集成层承接业务领域建模成果，将核心系统按照业务领域建模体系进行整体规划，形成可供全行IT系统复用的业务中台能力，提供生产各业务系统必须的业务组件；通过服务治理与组合的低代码能力，快速支撑业务创新；服务网格为传统应用、迁移到云原生分布式架构下的应用互通提供技术保障。
应用架构层面，云原生分布式核心与传统瘦核心或分布式核心重大区别是：

不是：简单的将核心系统按照业务条线划分为客户、存款、贷款等应用，采用分布式技术重新实现一遍，很多公共的能力（例如产品管理、合约管理等）都需要各个应用重复建设，数据层面不互通；
而是：将核心系统按照业务领域建模体系进行整体规划设计，形成可供全行IT系统复用的业务中台能力，提供业务构件；通过服务运营与编排，使用业务构件快速进行业务创新。

3.3.2.1应用架构中台化
1.云原生分布式核心中台化应用架构
通过多年自身金融业务实践和实际参与银行客户核心系统转型项目，基于标准化业务建模和技术建模成果，建议将用户、产品、合约、额度、交易、账户、计价等金融服务的核心商业要素数字化、中台化，构建出全行级中台能力地图，从而支持前台业务的快速迭代。