7Fresh系统快速构建之路——DDD领域驱动设计实践

7Fresh是京东第一个线上线下融合落地的零售创新业务模式,店内有大量设备的集成,设备供应商达50多家,针对线下业务的特点,团队独立规划和设计POS收银系统、店内生产系统、加工系统、货架陈列系统、魔镜系统、餐饮系统、自助收银系统等共60多个系统,对接电子价签、电子秤、包装机、无人购物车、门店客流检测等几十种设备。

第一期上线40多个系统,后续又高效上线了其他新增20个系统,短时间内完成了别人口中不可能完成的神话。

【京东技术沙龙】是由企业信息化部/京东大学技术学院联合京东集团各技术体系共同举办,针对京东研发内部,每月1期,分享前沿技术成果及热点话题。建立“技术交流平台”、促进“技术资源共享”、解决“工作痛点”。

经过小编的整理和7Fresh架构师团队的修订后,为大家呈现,带您一同回顾7Fresh系统从0到1的快速构建之路!

01

系统构建历程

7Fresh与京东商城一样拥有一整套的交易系统、一键结算系统,但和线上不一样的是,我们还有很多线下系统,店内的生产、加工、库存管理、餐饮等等。

整个项目从产品调研、架构设计,到第一期上线经过了2个半月的开发。第一期就有40多个系统同时上线,基本能把所有的业务系统运行跑通,之后又增加了很多餐饮类,地推类和线下有关的新需求,现在也依然在落地新的需求中。

02

快速开发的主要原因

1、用DDD进行战略设计

  • 分治
  • 界限上下文内的技术无关的通用语言
  • 薄薄的技术集成层隔离业务变化

2、虚拟组织保障设计落地

  • 早期组成虚拟的架构师组织,后期产品也加入
  • 不断摸索方法论和原则

3、其他因素

  • 多团队协同包括成都、武汉、技术拓展等部门
  • 框架和组件积累,之前积累的pop-spring-boot和popdesign及脚手架
  • 业务团队的大量参与,与业务开展同步进行

03

我们对DDD的理解

1、首先是战略部分,这也是我们认为实施比较好的部分:

(1)划分和集成界限上下文。

这个虽然不是技术上的问题,但是最关键的还是对业务的理解,跟部门业务专家一起工作很重要,另外是参考了京东现有的情报,做了很多的改进。怎么把系统进行解耦,这个领域边界界定以后,首先上下文最重要的是界定通用语言,就是在一个上下文里边有一套完整明确的概念:

一个店就相当于一个仓,WMS开始设计的时候概念方式是管理统一SKU。而我们线下店有做蛋糕、做餐饮这些场景,加工的原材料也应该在系统里,WMS如果强绑定销售商品的SKu的话,那我们线下店就没法管理了。

所以,经验就是不能把一个概念应用超出上下文界定的领域,这样做的好处就是,通过这种方式隔离一些变化,适应更多的场景,实现解耦。

(2)面向服务集成而不要面向数据集成。

如果这样的话就能解耦了吗?

随着一些新需求的推进,还是发现里边有些耦合存在。总结的经验就是:下游的系统应该对需求做抽象,提出自己的标准,这样才能实现解耦。做DDD领域设计的时候,不应该受到具体架构风格、模式的影响,不管是微服务的还是单体加模块化的风格,最终的效果应该都是一样的,界限分明。

(3)技术无关地考虑领域模型,比如使用类图,定义和功能场景甚至状态图和对象快照。

2、使用DDD进行战略设计相对容易落地,收益明显。在使用DDD进行战术设计却遇到了重重困难。

战术部分在落实到代码层面遇到了困难。看过业内关于DDD的分享,发现其实大家能把战术层面把DDD落地的,其实都做的不理想。以下是我们对战术层面上的理解:

(1)代码即设计

代码即设计,在代码中尽量表现出想要的设计意图和领域意图,但是像性能这类的属性很难表现出来,能够实现但却不能表现意图。而领域设计是比较能在代码层面表现出来的。

难点一:聚合根识别困难

难点二:贫血模式。基本我们的框架和思路,很机械式的编码和设计,很难实现上述的目标;

难点三:按DDD的理论,聚合根之间不赞成使用数据库事务,成本很高。

(2)用包来体现实体概念

左图中间的部分就是领域模型,这也是现在比较通用的方式,领域模型包括领域对象、领域服务,领域对象总是要被存储的,这就需要依赖于仓库,仓库在领域下应该是个接口,我们认为领域应该依赖于技术实现,存储的实现应该在另外一个包下,通过依赖倒置的方式,把领域模型包含的东西和基础设施层分隔。

(3)订单状态变更的例子

现在有很多不同类型不同场景产生的订单,它们之间的状态变更是不同的,从未支付到已支付再到在拣货,当中有很多状态是不一样的。如下:

从设计层面可以划分不同的状态设计,但是最后状态无非是当前状态,编码实现上就目前来看,写在service层到处都是判断……,来一个新业务就要改一次新判断,但是我们现在从构思想,简单来说先把它放在order对象里,因为这只跟order的数据有关系。

从集成的角度来说,如果支付系统接收到支付完成的消息,我们把消息payevent变成一个事件,传给了orderservice-changestate,orderservice里边非常简单,把order从仓库里边加载出来,然后调动方法即可。

大部分业务里的规则还是在orderchangestate方法里。这么做的好处就是,它能够表达出我想要的设计意图,如果分散在其中的话,可能只与设计文档不一致。

第二个就是说,把领域规则识别出来放在对象中会带来额外的好处是,领域规则往往跟外部是没有关系的,很容易做纯粹的自动化的单元测试。

(4)数据一致性和领域事件

一个微服务内部的多个聚合根,可以使用数据库事务保证数据一致性,虽然不完美,但还算实用。用领域事件去做最终一致性成本太高。

两个上下文之间用MQ做最终一致性

京东技术 ∣关注技术的公众号

原文发布于微信公众号 - 京东技术(jingdongjishu)

原文发表时间:2018-04-23

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏前沿技墅

架构整洁之道:优秀设计或多余,有效设计最可取

一位经验丰富的软件工匠,也是追求简化软件设计和实现的思想领袖。他是畅销书《实现领域驱动设计》和《响应式架构:消息模式Actor实现与Scala,Akka应用集成...

671
来自专栏数据和云

2015 Oracle技术嘉年华 PPT下载

2015年11月20日~21日,Oracle技术嘉年华大会在北京召开,感谢为大会奉献精彩演讲的嘉宾,现在PPT资源已经全部整理完毕,现在开放下载。 链接: ht...

2835
来自专栏互联网数据官iCDO

19个令人大开眼界的可靠消费者研究数据源

译者:董梁 本文长度为3058字,预估阅读时间5分钟。 我们今天要向大家分享19个令人大开眼界的可靠消费者研究数据源。 Kyle的注释: 数据是分享洞察、支持...

2646
来自专栏飞总聊IT

上周上市的大数据公司MongoDB的前生今世

声明:本文仅代表个人观点,和本人公司无关。 1 本文由本人在极客时间的专栏系列文章(4篇)总结而成。感谢极客邦允许我发表在公众号上。文章写得不够详细,分析也不够...

3547
来自专栏企鹅号快讯

2018年最具就业前景的6大编程语言!

2018年即将到来,Coding Dojo(编码道场)近期发布了 2018 最具就业前景的 7 大编程语言。 分析了来自 Indeed 的25门编程语言、栈和框...

1896
来自专栏云计算D1net

谷歌PaaS在AWS弹性Beanstalk前横插一腿

在平台即服务市场中,谷歌公司是一名先行者,这使得他们与早期实施者保持着紧密的联系,但它是否能够在较长的时间内击败弹性Beanstalk呢? 在IaaS市场中,亚...

3317
来自专栏Cloud Native - 产品级敏捷

微服务架构 (七): 微服务粒度设计上的核心设计原则与思考的面向

2016.8.19, 深圳, Ken Fang 架构师在设计微服务时, 需把握一个核心的设计原则: 微服务 “外部的世界” 远比 “内部的世界” 重要。 微服务...

2265
来自专栏程序员互动联盟

嵌入式,过时了没?

疑惑一 作者你好,我是本科生,之前是学java的,但是后来签的工作是嵌入式软件开发,我对嵌入式开发不太了解的,这行有前景吗? 这是小编在后台接收到的小伙伴的疑惑...

3367
来自专栏大数据挖掘DT机器学习

爬取拉勾网大数据相关岗位薪资信息存到excel,并作数据分析

今天就进入实战演练:通过Python来编写一个拉勾网薪资调查的小爬虫。 第一步:分析网站的请求过程 我们在查看拉勾网上的招聘信息的时候,搜索Python,或...

3848
来自专栏安恒信息

你在微信不经意点开的链接 可能成为别人追踪你的标靶

一条八卦新闻、一个微信红包、一次小游戏邀请……你会不会在微信对话框中经常收到类似链接?如果你不小心点开了,那你的地理位置信息很有可能就被对方“盯上”了。

944

扫码关注云+社区