【实战示例】DDD领域建模打法之——对象设计

目录

前言

商品子领域

SKU和SPU

粒度到哪一层?

对象设计

商铺子领域

订单子领域

支付子领域

顾客子领域和售后子领域


前言

前面我们一共进行了三步:

1.需求建模、2.领域建模、3.原型设计

1.需求建模

本文是DDD实战系列文章中的一篇,前面已经聊过了什么是面向对象的需求建模:

面向对象的需求分析方法-CSDN博客

以及我们这个实战系列中要做的一个小的购物商城的需求是什么样的,通过面向对象的需求建模方法,我们建模出了需求:

【实战示例】面向对象的需求建模_面向对象需求建模-CSDN博客

2.领域建模

需求建模出来后,就是DDD领域建模的核心——领域建模,也是整个DDD所力求的核心:通过合理的建立概念之间的关系,让系统中对象之间的关系最合理,以求可以很方便的应对后续的需求变动。我们总结出来的落地打法:

  • 系统的参与者肯定各自是子领域:顾客子领域、商家子领域、管理员子领域

  • 所有参与者共用到、共同参与的东西也是子领域:订单子领域、商品子领域、支付子领域、售后子领域

按照这个打法完成了领域建模:

【实战示例】领域建模_领域建模 实战-CSDN博客

识别出总共有:商品子领域、商家子领域、物流子领域、支付子领域、订单子领域、顾客子领域、售后子领域。

3.原型设计

需求建模出来后和领域设计可以同步进行的是原型设计,我们用Axure画出了一个简单的系统原型图:

【原型设计】Axure快速入门教程_axure使用教程-CSDN博客

【实战示例】原型设计_购物商品原型-CSDN博客

完成上面三步后,接下来就是根据领域建模细化出后端的对象设计了,也就是大致的类图。

商品子领域

SKU和SPU

商品子领域是整个系统的核心,要思考很多问题。首先是:

如何实现一个商品多个具体型号,如我们在京东或者淘宝上点iPhone15,这是一个单个商品:

点进去之后是不同套餐:

对商场来说iPhone15才是单个商品,而不是“iPhone15-白色-128G”是个具体单品,不然就不能实现这种商品列表点击进入商品详情的效果,也不好管理对吧?

所以这里我们要引出几个概念

  • SPU,标准产品单元
  • SKU,标准库存单元

对于商城来说Product是个具体商品,SPU定义这个Product有哪些参数,SKU去具体填充这些参数以及售价和库存量等。

拿上面的iPhone15来说,它的Product对象应该就是:

{"name":"iphone15"}

SKU就是:

[{"name":"颜色","type":"text","unit":""},{"name":"版本","type":"int","unit":"GB"}]

SPU就是:

[{"颜色":"白色","版本":"128"},{"颜色":"黑色","版本":"512"}]

也就是个Product是个概念,SPU定义这个概念的规格有哪些,可动态随意扩展,SKU去填充这些规格参数,一个Product要有SPU和SKU才能是个具体的实际商品。

粒度到哪一层?

在电商中往往还要考虑一个问题,就是整个系统对商品的控制粒度到哪里?比如上架/下架、设置运费模板、设置优惠活动、设置销售周期,这个粒度到Product层,还是到SKU层。其实不难发现很多产品不同颜色的价格是不一样的,有些颜色它的销售策略或者活动策略就是不同。所以我们整个系统直接将管理粒度拉到最细,全部打到SKU层面。

对象设计

商铺子领域

商铺要完成的核心是运费模板的设计,运费模板关联地区模板、关联非本子领域的商品对象。

订单子领域

订单子领域的核心是订单,关联订单项、关联物流信息、关联用户,关联非本子领域的商户、销售信息、退款交易、支付交易。

支付子领域

支付子领域里面要考虑的东西有一点多,一次交易要考虑到支付交易和后续可能的退款引起的退账交易,然后要有记录,记录分为分账记录和退分账记录。

顾客子领域和售后子领域

顾客子领域只剩一个购物车功能,这里偷个懒就不画了,很简单,售后功能暂时不慌作,所以先跳过。后面作者回来补充。本文主要就是给大家聊聊落地的DDD打法分几步?每一步该做什么?这一套下来会很清晰的做出一个面向对象的全流程,很便于应对以后的修改。