开头先说两句
小刀博客: https://www.lixiang.red
欢迎留言一块儿讨论java
项目背景
因脱敏关系,这里面三个角色就用A,B,C来代替,能够抽象理解为, A 是需求发起方,B是平台运营方, C是资源提供方. 代入今天的商品模块,就是A 要商品, C能提供商品.B 来进行中间的逻辑判断可否提供对应的商品redis
设计之初及一些方法
在给本文起标题的时候犹豫了下,是写架构设计仍是写DDD呢,后来想了一想,这个项目也是在尝试DDD,用的还不是很成熟,就仍是写了架构设计.spring
以往咱们说想要设计个什么东西的时候,而后就开始想要建什么表,表里面有什么字段,而后开始打开navicat/datagrip建表,而后写代码对表进行增删改查,而后交工设计模式
那么如今咱们来一块儿换种方法思考下,在小刀看来,架构设计分两部分,一部分是业务架构,一部分是技术架构.springboot
技术架构
对开发人员来讲,技术架构不是很难的事,由于不少能够开箱即用的东西,如spring全家桶. 对于项目初期要求快速上线快速迭代,因此基本上也没什么个性化的配置调优,用默认的先跑起来就行, springboot+springmvc+mybatis+redis 这一套估计你们均可以搭一个项目环境开发起来,咱们的这个项目也是基于这个技术选型之下微信
业务架构
这个是今天的重点,咱们先不谈表,先聊业务,而后一步步的往下走mybatis
提取语言关键词
而后提取出各个关键词,从上述项目背景中,咱们能够提取出如下几个概念:架构
A,B,C,商品,匹配规则.mvc
从这些关键词中,咱们再进一步划分,有业务相关,有领域(基础)相关的iphone
业务关键词有: A,B,C
领域关键词有: 商品,匹配规则
而后咱们能够用这些关键词去组织语言从新描述这个事情:
A 发布了对 商品 的需求
C 提供了 商品 的信息
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 等领域概念没有画出来,小伙伴们能够对照本身的模块,设计出本身的结构图
最后的建表工做
说了这么多,终于到建表这一步了,真正到这一步时,其实没多少要说的,对每一个实体建张表,而后设置对应的字段属性,而后写增删改查给领域调用, 对于设计,你有什么见解? 欢迎各位小伙伴留言一块儿讨论
本文分享自微信公众号 - java技术大本营（java-ideashare）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。