架构设计-商品模块的领域驱动设计思路及实现

开头先说两句

小刀博客: https://www.lixiang.red
欢迎留言一起讨论

项目背景

因脱敏关系,这里面三个角色就用A,B,C来代替,可以抽象理解为, A 是需求发起方,B是平台运营方, C是资源提供方. 代入今天的商品模块,就是A 要商品, C能提供商品.B 来进行中间的逻辑判断能否提供对应的商品

设计之初及一些方法

在给本文起标题的时候犹豫了下,是写架构设计还是写DDD呢,后来想了一想,这个项目也是在尝试DDD,用的还不是很成熟,就还是写了架构设计.

以往我们说想要设计个什么东西的时候,然后就开始想要建什么表,表里面有什么字段,然后开始打开navicat/datagrip建表,然后写代码对表进行增删改查,然后交工

那么现在我们来一起换种方法思考下,在小刀看来,架构设计分两部分,一部分是业务架构,一部分是技术架构.

技术架构

对开发人员来说,技术架构不是很难的事,因为很多可以开箱即用的东西,如spring全家桶. 对于项目初期要求快速上线快速迭代,所以基本上也没什么个性化的配置调优,用默认的先跑起来就行, springboot+springmvc+mybatis+redis 这一套估计大家都可以搭一个项目环境开发起来,我们的这个项目也是基于这个技术选型之下

业务架构

这个是今天的重点,我们先不谈表,先聊业务,然后一步步的往下走

提取语言关键词

然后提取出各个关键词,从上述项目背景中,我们可以提取出以下几个概念:

A,B,C,商品,匹配规则.

从这些关键词中,我们再进一步划分,有业务相关,有领域(基础)相关的

业务关键词有: A,B,C

领域关键词有: 商品,匹配规则

然后我们可以用这些关键词去组织语言重新描述这个事情:

1. A 发布了对 商品 的需求

2. C 提供了 商品 的信息

3. B 使用 匹配规则 验证 C 的 商品 是否满足 A 需求的 商品

这时候,在第3句中已经产生了歧义,因为C 提供的 和 A 发布需求使用的实际上是两个不同的实体. 比如: 小刀说,我想买个16G的iphone8 , 京东说我有,3000块,淘宝说我有: 2000块. 从这看来,这是两个不同的实体
因此我们重象出一个新领域概念:产品,同时修改语言为:
1. A 发布了一个 产品 的需求
2. C 提供了一些 商品 的信息
3. B 使用 匹配规则 验证 C 的 商品 是否满足 A 的 产品 需求

这样一来,只有匹配规则是一个黑盒子了,但这块是业务逻辑,在架构设计之初,可以不做太多考虑,用一个设计模式中的模板模式定义一个方法,以后再实现.

深入业务场景

目前为止的业务架构设计已提取了基本关键关键词元素,后续的场景就是以这些元素为主角去完成我们现实中的需求,这里和测试用例的设计比较像了,何为深入业务场景,就是和领域内专家多讨论,从讨论中提取业务场景模型,然后用我们提取出来语言关键词描述清这些场景.

当然不是每个公司都请得起领域专家,更多的需要设计者自己去思考业务,我们自己即模拟开发人员,又模拟业务人员.还是以上述小刀买 16G的iphone8为例, 京东说我虽然贵,但是我送充电器,送耳机,送膜. 淘宝说我最便宜,只有裸机一个. 同时要注意的是,充电器,耳机,膜这些本身也是单独的商品,也就是说,在某些场景下,商品并不是最小销售单位. 这些商品的组合,或者这些商品衍生出的一个新概念才是最小销售单位,我们可以称之为: sku
通过上述场景我们提炼出了 sku 这个关键字,还有很多场景可以深入,比如小刀需要的是一批手机, 然后京东有一部分, 淘宝有一部分,这种场景下可以再提炼出类似于 拆包 这样的关键词

强化领域概念,划分上下界

经过我们的初步分析的深入提炼,我们现在共记得到了如下几个关键字:
业务: A,B,C 领域: 产品,商品,SKU,匹配规则
本段我们就领域中的概念继续提炼
一个产品对应多个商品,一个商品对应多个sku ,sku既是最小销售单位,也是最终和业务域产生业务关联的实体.因此,别的领域想要获取商口域的相关信息,都要传入一个sku实体.最后我们可以得到这样一个图

图只是简单示意了整体结构,其实还有repo , spec 等领域概念没有画出来,小伙伴们可以对照自己的模块,设计出自己的结构图

最后的建表工作

说了这么多,终于到建表这一步了,真正到这一步时,其实没多少要说的,对每个实体建张表,然后设置对应的字段属性,然后写增删改查给领域调用, 对于设计,你有什么看法? 欢迎各位小伙伴留言一起讨论