DDD 九月 22, 2024

领域驱动设计实战

文章字数 5k 阅读约需 5 mins. 阅读次数

需求概述

需求为一个简化的外卖平台,包括下订单、支付、取消、商家接单、准备、派送等功能。

架构风格选择

采用领域驱动设计方法进行问题空间分析及解空间设计。划分顾客、商家、骑手、订单、通知五个限界上下文,每个上下文成为一个微服务。服务内部采用分层架构。服务之间以开放主机服务及事件驱动架构。数据库逻辑隔离,通过事件机制保证最终一致性。

统一建模语言

  • 商家(Merchant)
  • 注册
  • 顾客(Consumer):自然人通过商家提供的服务,注册成为顾客
  • 签约
  • 骑手(Courier):商家签约自然人为骑手
  • 骑手状态(CourierStatus):
    1. 可分配接单(Available):订单派送完成后立即空闲
    2. 不可分配接单(Unavailable)
  • 账户(Account)
  • 账户状态(AccountStatus)
    1. 激活(Actived)
    2. 锁定(Locked)
  • 预存款(Charge):顾客向账户内预存款(充值)
  • 菜单商品(MenuItem Product)
  • 商品状态(MenuItemStatus)
    1. 待上架(Pending)
    2. 已上架(Up)
    3. 已下架(Down)
  • 订单(Order)
  • 订单商品(OrderItem):订单可以包含多个订单商品,订单商品包含金额和数量
  • 订单状态(OrderStatus):
    1. 已创建(Pending):未支付
    2. 已提交(Approved):已支付,产生消费记录
    3. 商家已接受(Accepted):指接受工单,需有空闲骑手
    4. 准备中(Preparing)
    5. 准备完成(ReadForPickup)
    6. 派送中(Pickedup)
    7. 派送完成(Delivered)
    8. 已取消(Cancelled)
  • 支付
  • 消费记录(Accounting):顾客支付订单的消费记录
  • 消费记录状态(AccountingStatus)
    1. 待支付(Pending)
    2. 已支付(Paid)
    3. 已退款(Returned)
  • 退款:订单取消时产生退款
  • 工单(Ticket):
    顾客支付订单后,订单变为已提交状态,并自动创建工单。
    商家浏览工单,并对工单进行接受或拒绝。
    接受工单时,会创建配送任务,并设置预计派送时间。在预计派送时间前后30分钟内有空闲骑手(无已分配的派送任务)时,随机挑选一个骑手,,修改派送为已分配状态,接受工单成功。
    工单接受失败(商家无法准备、没有空闲骑手)会导致工单取消、订单取消,并退款。
  • 工单状态(TicketStatus):
    1. 已创建(Pending):待接单
    2. 已接受(Accepted)
    3. 已备餐(Prepared)
    4. 待取餐(ReadyForPickup)
    5. 已取餐(PickedUp)
    6. 已取消(Cancelled)
  • 派送(Delivery)
  • 派送状态(DeliveryStatus)
    1. 待分配(Pending)
    2. 已分配(Accepted)
    3. 已送达(Delivered)
    4. 已取消(Cancelled)
  • 预计派送时间:商家接受工单的时间
  • 计划送达时间:计划派送时间 + 30 分钟
  • 实际派送时间:骑手取得订单商品开始派送的时间
  • 实际送达时间:骑手实际完成送达时间
  • 通知(Notification):为顾客、骑手、商家发送手机通知
    订单已支付后,给顾客发送支付提醒
    账户有退款时,给顾客发送退款提醒
    顾客注册时,给顾客发送短信验证码
    有新的已分配派送时,给骑手发送派单提醒
    派单取消时,给骑手发送派单取消提醒
    工单准备完成时,给骑手发送提醒

快速建模法

名词建模

识别业务服务规约中的名词

动词建模

识别业务服务规约中的动词,判断动词对应的领域行为是否产生了过程数据,如果有,则将该过程数据识别为领域概念

归纳抽象

针对有定语修饰的领域概念进行归纳抽象

确定关系

确定领域概念之间的关系

领域分析模型精炼

领域分析模型与限界上下文

  1. 领域分析模型
  2. 区分实体和值对象,设计聚合
  3. 限界上下文及上下文映射图

bounded-context

领域事件及 Topic

事件风暴方法分析命令、领域事件及聚合:

domain-event

events

事件驱动机制及事务管理机制

  • 本地事件表保存事件以保证事务一致性
  • 定时轮询事件表中未发送事件,将其转换为消息发送至消息队列
  • 消息生产者通过事件表的乐观锁保证消息的成功发送,消费者保证消息处理的幂等性

工程结构设计

参考结构

mapping

package

以上两张图片引自 《解构领域驱动设计》

实际结构

服务名

  1. order:订单
  2. consumer:顾客
  3. merchant:商家
  4. courier:骑手
  5. notification:通知

包划分

  1. com.neusoft.hackathon.order.north:北向网关,包括本地和远程调用;相当于领域模型对其他限界上下文暴露的接口;前后端接口的适配也可以在这个包里完成,如 north.controller
  2. com.neusoft.hackathon.order.domain:领域模型,尽量保持稳定,需求不变领域模型尽量不变
  3. com.neusoft.hackathon.order.south:南向网关,包括端口和适配器,用来调用其他限界上下文接口以及资源库
0%