如何设计一个业务系统

1. 本文的目的

  1. 希望能对设计过程有一个整体的概念
  2. 希望能够参照这个过程，完成一些简单的业务系统设计
  3. 本文重点针对于业务系统设计和分析。不太涉及系统设计的其他方面，如性能，可靠，可见等等。

PS:

  • 也希望业务系统设计不再会是个人发展的瓶颈

2. 背景

现阶段，对人员的需求已经不再是能有一个简单的需求把做出来。更可能是能独立承接一个有点复杂的需求。比如拼团，比如加速包, 比如套票。有一个略微复杂的流程，有更多的场景，涉及到更多的状态和角色和交互。

在这种情况下，按照以往直接想想就开始做的方式，已经很难得心应手的把东西做出来了。经常会遇到:

  • 做了一半，感觉好像不太对
  • 写着写着写不下去了
  • 怎么写都有些地方考虑不周到

在我来看，缺的就是一个设计的过程:

  • 如何在不同的角度去分析这个需求
  • 如何将一个复杂的问题拆解成几个更小的子问题
  • 如何将一个不是很复杂的子问题落实到模块/代码中

过去也会写好一个设计文档, 再和大家去讲, 但是效果感觉并没有很好。借着这次拼团的系统，希望能把这个过程剖析的更具体一些, 看看是否能给大家更多的助益。

3. 设计的目的

为什么要设计?,

  • 因为不设计已经做不下去了。

评估一个设计的好坏，就看能否清晰的表达出 要做什么 ， 怎么做 ， 为什么要这么做 。

为什么要详细的设计?, 在用户流程，模块，复杂对象的生命周期等不同的维度分别做设计。

  • 因为脑力有限，无法同时关注这么多的细节，所以要分层，要分离不同的关注点。在不同的层面上去关注不同的具体的事情。

一句话来衡量: 设计就是让一个看起来不太可能能做好的东西变的很显然能做好

4. 如何设计

4.1. 原始需求分析

划重点: 不关心系统，不关心当前是什么样，不关心有哪些模块。只关心一点: 系统对外体现是什么样. (对外并不仅仅指对外的用户视图。只要是外部能观测到的，都是系统的对外体现)

这一阶段，关注的就是系统整体对外的承诺。到底要做什么。

4.2. 用户场景 && 场景分析

这一步，主要目的是把对外承诺细化。看看会有哪些不同的流程, 不同的场景。

常见的分析方法就是: 有哪些用户，哪些角色，分别关注哪些数据，数据流或者操作流大约是是什么样的。

比较常见的展示工具就是时序图了。

这一阶段, 关注的就是对外承诺的详细信息，对内会涉及到哪些场景和状态。从而可以分析出，内部需要哪些模块，如何配合。

4.3. 系统概要设计

在这个阶段，主要的工作是，基于上文中的具体场景，分析出需要 哪些模块 来承载各自的功能，如何配合。

我认为，这个也是从需求到落实最关键的一步。因为在这里，需要划定 模块的职责和边界, 以及, 如何通过这些职责，组织出所需要的功能。

常见的分析方法也一样是，基于上文中的系统需要提供的功能，如何分解让各个模块配合实现。

PS: 模块的拆分是一个迭代的过程(玄学)，一般是先分，然后看模块间交互，然后调整。满意为止…

除了模块拆分以外，还有一些重点问题可以单独拿出来放在这个模块讨论。

4.4. 模块内部设计

具体方法其实类似，但是需要更多考虑一点， 如何用内部不可见的存储/状态，去实现外部的行为或者感知 。

4.5. 任务分解

在这里，更多是从一个这个业务需求的负责人角度，来看，需要哪些地方有工作，哪些工作，如何分解，如何跟踪。让整体的业务需求更可控。

5. 案例分析

5.1. 票务系统设计

整体内容相对完善一些，供参考: 票务系统设计文档下载

5.2. 拼团

5.2.1. 拼团需求分析

  • 商家能创建/参与拼团活动
  • op 能审核&发布该拼团活动
  • 当拼团活动发布之后，符合一定的标准，用户可以在商品详情页看到
  • 用户可以发起或者参加某个团
  • 团符合成功标准，则拼团成功。超时未符合，则拼团失败
  • 拼团成功，则用户购买成功。失败，则退款
  • 购买成功后，用户能看到订单, 能看到后续的发货流程，正常消费。
  • 如果拼团成功，但是超卖，可能也需要退款

5.2.2. 拼团用户场景

  • 商家
    • 创建拼团活动
    • 修改拼团活动内容
    • 查看拼团活动审核情况
  • 管理人员
    • 审核拼团活动
    • 驳回拼团活动
  • 用户
    • 基于项目查看拼团活动
    • 创建一个拼团
    • 参与一个拼团
    • 查看拼团进度
    • 拼团成功后查看订单，消费票券
    • 拼团失败后退款

5.2.3. 拼团场景分析

  • 商家创建拼团活动

    /assets/blog/2018/06/04/如何设计一个业务系统/merchant-tuan-campaign.png

  • 用户创建拼团

    /assets/blog/2018/06/04/如何设计一个业务系统/user-tuan.png

5.2.4. 拼团系统概要设计

  1. 重点概念解释

    • 拼团活动

      制作领域的概念，包含参与拼团活动的项目，场次，票档，拼团价格，结算价格，有效期，是否公开等信息

    • 团

      第一个拼团订单创建完成，会生成一个团。用于承载拼团动作的结果

    • 拼团订单

      用于承载针对某个团的参与动作，以及支付行为, 驱动后续的订单生成等

  2. 模块划分
    • 拼团活动模块
      • 负责拼团活动的创建，审核，发布功能
      • 负责拼团活动的查询
    • 拼团模块
      • 负责拼团的创建
      • 负责参团
      • 负责拼团的信息查询
      • 负责拼团状态的维护，包含拼团成功，超时失败等
      • 负责拼团成功后对应订单的创建
      • 负责可能的超卖后的退款处理
    • 支付模块
      • 负责拼团订单的支付
      • 负责拼团订单的退款
    • 订单模块
      • 负责拼团订单对应的商品按照指定价格和结算价进行下单

5.2.5. 拼团模块内部设计

  1. 拼团活动模块
    1. 与外部模块关系
      • 提供拼团的定价和结算信息给拼团模块
      • 根据项目，提供审核通过的拼团活动的详细信息，用于演出模块展示拼团活动和最低拼团价
    2. 内部逻辑
      • 同一个项目，选择不同的票档参与拼团，设置拼团价格和库存
      • 拼团活动以项目为维度，可以审核通过或者驳回
      • 可以设置开始时间和结束时间
      • 如果考虑到一定的灵活性，审核的维度可以到票档。
      • 保证最终成团的售卖数量不超过拼团活动设置的最大库存
        • 倘若超卖，则支付成功，购买失败，做退款。产品上需有说明
        • 若拼团成功 3 单，其中 2 单有库存，一单超卖失败, 则仅退款一单
        • 可以是判断是否当前团的最后一个团员,如果是，那么提交订单时就锁定整个团的库存, 如果不是，那么提交订单时不锁定整个团的库存
    3. 外部接口
      1. 创建拼团活动
      2. 更新拼团活动
      3. 拼团活动审核
      4. 根据项目 ID，查询拼团信息(支持是否过滤 shopId)
        1. 一个商家一个项目多个票档，叫做一个拼团活动
        2. 一个项目可能会有多个拼团活动，选择其中拼团价最低的有库存的票档用于展示
        3. 如果有 shopId 的过滤条件，只查询指定 shopId 的拼团活动
      5. 批量根据项目 ID，查询拼团信息(支持是否过滤 shopId)
      6. 根据拼团活动票档 Id, 查询结算价和数量

    4. 模型设计

      • PinTuanCampaign
      字段名 字段类型 字段含义
      - - -
      id int 主键 ID
      effectiveFrom Date 拼团活动开始时间
      effectiveTo Date 拼团活动结束时间
      status int 拼团活动状态，已提交，已驳回, 已发布
      isOpen int 是否公开
      activityId int 演出 ID
      • PinTuanCampaignItem
      字段名 字段类型 字段含义
      - - -
      id int 主键 ID
      pinTuanCampaignId int 拼团活动 ID
      ticketCategoryId int 票档 Id
      activityEventId int 场次 Id
      salePrice int 拼团活动售价
      count int 拼团活动总库存
      status int 票档审核状态, 未通过，已通过
      sellStatus int 票档售卖状态，开启，关闭
    5. 拼团活动审核的维度
      1. 基于票档/基于项目/基于项目当前未审核通过的部分
    6. 拼团活动票档的修改
      1. 一旦审批通过后，不可以修改拼团价格
      2. 关闭状态下，可以调整库存
    7. 拼团活动如何保证(尽量)不超卖
      1. 在参团下单前，校验一次已参团人员的库存情况，如果库存不足，则不允许新团员参团
  2. 拼团模块
    1. 与外部模块关系
      • 成团后，驱动生成对应订单
      • 支付拼团
      • 拼团失败后，退款
    2. 内部逻辑
      • 创建拼团/参团订单，校验拼团商品价格
      • 支付拼团订单，创建拼团
      • 支付参团订单，参与拼团
      • 拼团超时未成功, 自动退款
      • 参团达到标准，拼团成功
      • 如果超卖，拼团订单退款
    3. 外部接口
      1. 创建拼团订单(包含发起团和参与团)
      2. 查看拼团订单详情
      3. 查看团的详情

    4. 模型设计

      • Tuan
      字段名 字段类型 字段含义
      - - -
      id int 团 ID
      ownerId int 创建团的人
      status int 拼团状态
      addTime Date 团的创建时间
      expireTime Date 团的有效期
      requiredNum int 成团订单数量要求
      • PinTuanOrder
      字段名 字段类型 字段含义
      - - -
      id int 拼团订单 ID
      payStatus int 支付状态, 待支付，已支付，已退款
      tuanId int 团的 Id
      userId int 拼团订单的用户
      count int 购买数量
      salePrice int 拼团价格
    5. TODO: 如何自动分配选座订单的座位
    6. TODO: 如何保证驱动生成订单动作的幂等

5.2.6. 拼团任务分解

  • 商家后台
    • 拼团活动列表页
    • 拼团活动详情页
    • 拼团活动列表页接口
    • 拼团活动详情页接口
  • op 后台
    • 拼团活动列表表
    • 拼团活动详情页
    • 拼团活动列表接口
    • 拼团活动详情接口
    • 拼团活动审核接口
    • 拼团首页运营位配置
  • android && ios
    • 项目详情页拼团入口展示
    • 商家项目详情页拼团入口展示
    • 首页拼团运营位展示
    • 商家列表页 && 列表页拼团价格展示
    • 个人中心增加拼团订单的入口
  • m 站用户侧发起/参加拼团
    • 项目的拼团活动入口
    • 拼团详情分享
    • 拼团详情页面(各种状态和操作参考 PRD)
    • 项目的拼团活动查询接口
    • 拼团详情接口
    • TODO: 拼团项目的场次和票档以及库存查询接口
    • 拼团确认订单页面
    • 拼团下单接口
    • 拼团支付
    • 拼团订单详情页
    • 个人中心增加拼团订单的入口
  • 拼团活动服务
    • 拼团活动创建，更新，提交，审核，发布接口
    • 拼团活动信息查询接口
  • 拼团服务
    • 拼团创建接口
    • 拼团参加接口
    • 拼团成功创建订单
    • 拼团超时未成功自动退款
    • 拼团超卖?
  • 订单服务
    • TODO: 能够根据指定的商品售价创建拼团成功后的订单

5.3. 套票

5.3.1. TODO: 补充完成设计文档