最近参与了一些电商营销中台等复杂业务系统的设计和开发,结合 DDD 和中台等,有一些架构方面的思考和体会,在这里记录一下。
做技术方案,核心是下面几个问题:
业务上怎么做?- 业务文档
技术上怎么做?- 技术方案
代码怎么实现?- 落地实现
明确了这几个问题,可以处理大部分日常需求开发,如果是比较复杂的业务系统,就需要拆解的更精细。
比如电商的商品管理、订单交易、促销活动营销中心等系统的开发和重构,业务相对复杂,开发人天在几个月以上,直接开发可能会老虎啃天,无从下手。
这时候可以通过一个流程化的模板来指导,如果抽象一个通用的流程,可以参考下面的套路:
业务拆解 > 复杂度来源 > 核心挑战点
领域驱动设计 > 业务过程分析 > 领域模型抽象 > 模型分解
分层组织 > 工程架构 > 模块化 > 组件化
考虑功能复用 > 可选路径 —( 业务身份,能力,扩展点,工作流程,编排)
方案产出 > 整体-模块-流程-细节 > 方案评审 > 最终方案
其中的功能复用环节,也是包括阿里在内的大部分业务中台的解决思路,供参考。
一、业务拆解
1.1 复杂度来源
为什么要关注复杂度?
我比较认同系统设计中「软件复杂度」的观点,架构设计的目的是为了解决软件系统的复杂度带来的问题,所以在设计架构时,首先就要分析系统的复杂度。
只有正确分析出了系统的复杂性,后续的架构设计方案才不会偏离方向;
否则,如果对系统的复杂性判断错误,即使后续的架构设计方案再完美再先进,都是南辕北辙,做的越好,错的越多、越离谱。
举个例子,医院管理应用的医疗管理系统(HIS),复杂度在于业务逻辑复杂,系统之间调用不清晰,
如果你设计一个 QPS 几万的高性能架构,就是没有解决系统的核心问题。
正确的做法是将主要的复杂度问题列出来,然后根据业务、技术、团队等综合情况进行排序,优先解决当前面临的最主要的复杂度问题。
1.2 核心挑战点
射人先射马,擒贼先擒王。
确定了复杂度,也就确定了系统设计的难点,在进行系统设计时,可以把难点列出来,各个击破。
以电商促销活动和优惠券为例,促销活动最大的复杂度来自营销形态的变化,营销最大的不变就是变,乱花渐欲迷人眼,各类促销方式