说在前面
程序员经常问的一个简单问题,2年开发、3年开发,5年开发、10年开发区别是什么?写代码还能写多久?
去年看过一篇大神的文章,总结了程序员不同阶段应该掌握的技能(当然此处不涉及管理相关内容,只说技术探讨):
- 1~2年开发,能完成基本的业务开发,属于cv阶段
- 3年左右开发,有一定的抽象能力,开始阅读一些源码
- 5~7年开发,阅读过大量源码,深究原理,规范化,系统健全性、更优化问题思考,开始思考系统架构、业务架构问题
- 10年以上开发,设计、架构、运维整体思考,算法、业务架构设计,底层服务设计搭建能力(当然10年早你可能已不做开发好多年了)
当然,上边总结的是说3年、5年..等时间段你必须要掌握的能力,也许你很厉害,3年已经达到5年甚至10年的水平也说不定.
引入重点
根据上段的总结,我们程序员的能力重点在于技术深度、技术广度和架构设计的把控!
今天我们重点说的就是设计能力,下面将从三个方面,和大家一起分享总结下:
做过支付系统概述
先看下曾经做过的一套支付系统的整体架构概览
支付系统架构.jpg
图中概括了支付系统主要服务分布.姑且暂分为了五层结构,下面抛开基础服务,简化系统,抽象出支付核心的简化版微服务架构:
简化后
核心微服务结构:
- 商户系统:商户关系维护,商户定制化配置管理
- 订单系统:交易系统,各种支付方式、提现、退款服务
- 账务系统:交易后的账务清分、核对、结算工作
- 通道系统:负责通道对接,管理各种底层通道
- 权限中心:接口权限、后台权限统一管理
支付架构引起的思考
看到上面两张总结的架构图,我们可以模糊地看出支付系统的整体架构设计,让我们再抽象一下,绘画出支付领域中的领域模型结构.进一步抽象、提取出核心后的模型图:
支付领域模型
商户模型、账务模型、订单模型、通道领域为核心的四部分领域模型,
其他的系统:
- 如网关作为订单的入口层,
- 如权限为商户的管理层,
- 如计费为商户与订单产出的业务行为层,
- 如结算为商户账务产生的资金流出口层....
等等,围绕四个核心领域,其他支付子领域逐渐成型,最后汇总到一起,成为一个支付微服务系统的领域架构模型.
👆的分析,我们引出DDD(Domain-Driven Design 领域驱动设计)思想(这里推荐大家有兴趣可以看下《领域驱动设计》这本经典书籍).领域模型是设计微服务的重要思想之一.大到微服务分层、整体架构设计、微服务拆分,小到微服务内部建设、代码结构设计,领域模型无处不在.
需求领域模型分析
领域驱动设计思想的核心就是:
- 概括总结业务领域中的核心思想,定义核心知识体系,再将核心体系拆分为一个个子领域.每个子领域界限清晰.
- 在业务的进化过程中,对于单个子领域业务膨胀,可进行拆分和重组,形成新的领域模型.
说的也点绕,大概意思应该就是微服务的核心,是各个微服务直接各司其职,界限清晰,并且可以随着业务发展,各服务间也存在这子服务吞并(聚合)和拆分的可能性.经典的领域模型主要分为四层结构:表现层、应用层、领域层、基础设施层.
四层架构
根据四层架构又延伸出CQRS思想(命令查询职责分离模式),其DDD的一种重要的实践模型:
CQRS最早来自于Betrand Meyer（Eiffel语言之父，开-闭原则OCP提出者）在 《Object-Oriented Software Construction》这本书中提到的一种 “命令查询分离CQS”的概念。其基本思想在于，任何一个对象的方法可以分为两大类：
- 命令(Command):不返回任何结果(void)，但会改变对象的状态。
- 查询(Query):返回结果，但是不会改变对象的状态，对系统没有副作用。
结合一个在线日志系统的例子,简单介绍下(这部分参考《浅谈命令查询职责分离(CQRS)模式》):
在线日志系统
C:代表命令,进行写操作,无需返回结果
Q:代表查询操作返回DTO数据
R:代表仓储数据,数据持久模型层,当然此处不一定指数据库,可能是一种对象模型,或者一组对象模型
S: Separation代表一种分离思想,表明命令操作和查询互不影响的设计思想.
但其实,说CQ彻底分离我理解是不应该的,在模型中任何操作都处于一个操作的上下文中,写操作和读操作有时又根据你的业务互相结合穿插的,这个时候就是要定义好模型间的交互方式,是事件驱动、是上下文引导还是责任迭代等等.
引出下一章我们的思考
通过支付架构,我们初步分析总结了微服务拆分中一些重要思想,引出了DDD和CQRS设计思想.对于支付架构,我们分析的是领域模型对整个支付业务的领域建设,微服务拆分.下面以我最近实际开发中的项目来描述一下,领域模型在单个项目中的使用.
网友评论