开发复杂业务系统，有哪些设计思路

开发复杂业务系统，有哪些设计思路

最近参与了一些电商业务中台等复杂业务系统的设计和开发，结合DDD和中台等，

有一些架构方面的思考和体会，在这里记录一下。

做技术方案，核心是下面几个问题：

• 做什么？- 产品需求
• 业务上怎么做？- 业务文档
• 技术上怎么做？- 技术方案
• 代码怎么实现？- 落地实现

明确了这几个问题，可以处理大部分日常需求开发，如果是比较复杂的业务系统，就需要拆解的更精细。

比如电商的商品管理、订单交易、促销活动营销中心等系统的开发和重构，业务相对复杂，开发人天在几个月以上，直接开发可能会老虎啃天，无从下手。

这时候可以通过一个流程化的模板来指导，如果抽象一个通用的流程，可以参考下面的套路：

• 业务拆解 > 复杂度来源 > 核心挑战点
• 领域驱动设计 > 业务过程分析 > 领域模型抽象 > 模型分解
• 分层组织 > 工程架构 > 模块化 > 组件化
• 考虑功能复用 > 可选路径 —（ 业务身份，能力，扩展点，工作流程，编排）
• 方案产出 > 整体-模块-流程-细节 > 方案评审 > 最终方案

其中的功能复用环节，是包括阿里在内的大部分业务中台的解决思路，仅供参考。

一、业务拆解

1.1 复杂度来源

为什么要关注复杂度？

我比较认同系统设计中「软件复杂度」的观点，架构设计的目的是为了解决软件系统的复杂度带来的问题，所以在设计架构时，首先就要分析系统的复杂度。

只有正确分析出了系统的复杂性，后续的架构设计方案才不会偏离方向；

否则，如果对系统的复杂性判断错误，即使后续的架构设计方案再完美再先进，都是南辕北辙，做的越好，错的越多、越离谱。

举个例子，医院管理应用的医疗管理系统（HIS），复杂度在于业务逻辑复杂，系统之间调用不清晰，

如果你设计一个QPS几万的高性能架构，就是没有解决系统的核心问题。

正确的做法是将主要的复杂度问题列出来，然后根据业务、技术、团队等综合情况进行排序，优先解决当前面临