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

业务重构主要是根据业界领先的理论和最佳实践建立企业级业务模型，进而基于模型逐层细化业务规划并向产品参数化设计转变。整个改造过程会以现状业务流程、数据和产品实践为基础，以待实现的业务需求为输入，以领域驱动设计思想为指导，形成具备模型驱动的核心业务架构体系。
传统的建模方式注重在企业级架构规范的范畴，能够以结构化的方式将战略，业务连接起来，但是从实际的落地来说，并不是传统建模方式关注的。以产品为例，结合领域分层的理念，下图能够比较清晰的表明企业级建模与系统架构设计两者之前的差异。

文章插图

同时传统的领域建模需要耗费大量的人力和资源，通常周期比较长，并不是所有的金融企业都能够参考建行的模式。往往全行级建模花费了数年的时间之后，整个格局，环境，战略又发生了变化，导致与时代的错配。在这个背景之下，敏捷，中台化，领域化建模的理念开始逐步进入大家的视野。

文章插图

核心系统领域化架构设计的原则
1.把核心系统打开，对原有核心的业务能力重新进行领域划分
2.把核心系统中的领域实体构建成微服务应用，实现核心服务能力的对外暴露，以及业务的松耦合
核心系统领域架构设计的进一步描述
1.将核心系统的通用领域提升到中台能力层次：客户中心、产品中心、合约中心
2.将核心系统的基础功能放入基础服务层，并构建成为对应的微服务应用：账户域、定价计价域，核算清算域、公共域、财务域等。
3.将核心系统中的各个业务产品放入产品服务层，各个业务产品的微服务包含了对中台能力服务和基础服务的流程编排组装。
经过中台化的重构之后，原有的业务流程建模和逻辑也会发生相应的改变，以定期支取为例，在经过中台化的建模改造之后的流程变成如下的模式

文章插图

4.2.1.2技术重构
回顾“面对误区的破局思维”的断言2、3、5
断言2：“基础不牢、地动山摇”，底层架构的高效稳定是第一目标。底层架构在起步阶段从“统一架构”更加容易走稳，再逐步进行局部优化和解耦。
断言3：核心架构中“非功能性需求”考虑要大于“功能性需求”。“非功功能性需求”应由技术架构来承载。业务模块可以解耦设计和分包，技术架构要统一规划和统一标准，实现核心领域的“统、分结合”。
断言5：核心转型最佳路径是追求“P/PC平衡”-- 产出和产能平衡。不仅仅是完成 “产出”任务（应用迁移），更为重要的是升级“产能”（技术架构能力）。“产能”（技术架构）升级后会推动更大的“产出”（业务价值），成为全行数字化转型的助推引擎。
从这三个重要的判断可以看到，核心云原生分布式转型需要一整套具备可伸缩、高可用的分布式金融技术平台作为支撑，核心应用技术平台的搭建整体包括DevOps平台、分布式中间件平台以及运维保障平台三部分。其中DevOps平台能提高核心应用开发上线的效率，主要包括有项目协作、代码托管、持续集成持续交付等；分布式中间件平台提供核心应用分布式能力层，提供了兼备应用分布式和数据分布式能力；运维保障平台主要承载核心业务系统高可用应急管理功能，提供支持容量管理、压测管理及容灾管理。