供应链商品域DDD实践时间不长,在实践过程也碰到了不少问题,有些找到了答案,有些还是在探索中。最近很荣幸受邀在供应链服务与创新团队做了一次分享,也想在这里把一些经验和想法分享给大家,借此抛砖引玉。
DDD是一套方法论,实践能否成功,我觉得不仅仅是个技术问题,更是执行贯彻实施的问题。
本文内容主要有两部分,DDD基本概念和DDD实施。基本概念包括通用语言、分层架构、DDD要素、边界上下文,DDD实施包括领域知识提取方法、思考方式的转变,在其中会穿插一些商品案例。
一 软件复杂性是什么?在开始DDD前,我们应该先回答的一个问题,我们为什么需要DDD?DDD是复杂软件应对之道,所以我们来一起看看,软件的复杂度到底在哪里?
在阿里两年,我感受很深的一个点是,我们不能持续交付不断演进的复杂软件,所以有1.0、2.0、3.0很多的版本,1.0搞不下去了,开始2.0,2.0也搞不下去了,开始3.0,不断循环。
阿里体系复杂度我看来是理解力、不可预测、协作力挑战三个方面。
1 理解力挑战需求规模庞大,业务数量和类型不断增多,业务相互耦合,不同业务相互影响。供应链有20多个行业,经销、代销、一盘货等各种商业模式,有跨境进口、国内业务、国际化业务,这些纵横导致系统复杂度大幅提升。业务系统多,边界划分不清,系统间依赖复杂。如供应链商品和共享SELL、AIC和IPM,一直都有边界问题,一个大项目过来,边界问题就得讨论上好几天。系统结构复杂,因为应对高并发、高稳定性等,功能性代码与非功能性代码混合,如业务代码混杂着各种兜底逻辑、灰度逻辑、重试等等,100行代码,可能业务代码不到30行。2 不可预测性挑战商业环境复杂多变,商业流程、规则多变。商业环境变化快,今年国际化、智能商业路由、考拉融合一下子都来了,在设计上很难前期都规划好。变化不可预测,软件系统变化也不可预测,带来设计挑战。3 协作力挑战大部分需求横跨多个团队,需求传递低效,需要反复沟通,方案产出效率低。团队角色多,业务概念多,没有统一语言,大家理解容易出现偏差。二 Why DDD?DDD设计合适的领域模型来映射现实中的业务,来有效地解决领域中的核心的复杂问题,是对OOAD的扩展和延伸,其解决之道:
分而治之,控制规模。关注点分离,应对理解力挑战,领域模型与存储模型分离,业务复杂度与技术复杂度分离。分层架构、分离核心,保持结构清晰,应对不可预测性挑战。统一语言,应对协作力挑战。三 DDD核心1 通用语言通用语言是提炼领域知识的产出物,获得统一语言就是需求分析的过程,也是团队中各个角色就系统目标、范围与具体功能达成一致的过程。
领域语言团队专有,负责解释和维护,相同名称概念,跨出这个团队,理解可以完全不一样。
领域专家、产品经理、开发人员共同的语言,这种语言是将领域专家和技术人员联系在一起的纽带。
在各种文档和平时沟通中,保持概念统一,特别提一下,做一个中文对照, 把概念和代码连接起来,在代码做到概念名称统一,减少混淆。
通用语言价值:
定义公共术语,减少概念混淆。沟通达成一致的提前,消除歧义和理解偏差,提升需求和知识消化的效率。概念和代码的统一语言,连接概念和实现。2 分层架构DDD第二个核心是分层架构,分离模型。优秀的架构应该是什么样子?关注点是分离的,可以分而治之,可测试性好。
一个人同时要做多件事情的时候,难免手忙脚乱。代码也一样,一段代码要处理各种事情的时候,也会乱成一团,所以我们要分解开来,各个击破。
商品域领域模型,在分层架构中的位置,如下:
CQRS模式:领域模型在应用层下面,command才走领域模型;查询和搜索服务不走。tunnel层,对接db、外部数据资源访问,领域和模型解耦,类似DAO。外部通过SPI和模型交互,六边形的adapter模式。3 DDD要素1)实体:有id,有生命周期和状态。有属性,有行为。外部事件会触发他的行为和状态变化。
实体和vo的区分,vo属性不能修改,使用final修饰。vo为表达模型减负,如商品有100多个属性,铺平开不能体现结构化,不能体现分层分类,将相似描述性属性分组封装成一个个vo。
2)为什么需要service,如批量操作多个实体、跨实体操作,如商品复制,转账。
商品域的工程架构:
serivce职责是:实体创建,持久化,跨实体操作等。不同层使用不同数据对象,tunnel使用dataobjects,面向存储,需要和实体相互转换。实体间有关系,可以动态加载关联对象;dataobjects只有数据,没有行为,一般也不会有关系。4 边界上下文边界 = 域或子域。领域对象在领域内才有确切的含义。出了这个边界,不能确保还是这个含义,如苹果。语言是有上下文的。在不同的上下文中,职责和任务不一样。人有多个角色,在家里是爸爸、在公司是小二,职责和任务不一样。上下文映射:
有了边界,那么领域如何输出价值呢?一个完全封闭的系统没有任何价值。常用的方式有:共享内核,防腐层等。防腐层:商品上游提供spi,spi不是直接对外开放领域模型,建立一层开放视图。采购域建立防腐层,收口商品的变更对本域影响。四 DDD实施1 DDD实施的挑战识别和提炼领域知识,并体现在模型代码上,强调一次“并体现在模型代码上”!防腐,保持模型不断演进,需要持续投入,保证DDD贯彻执行。人的转变,开发思考方式的转变。2 什么是领域知识?领域知识有分层分类,平台通用商业规则,是领域模型主要输入,商家个性化不能下沉到领域模型层。
3 领域知识提炼,需求和链路5W1H分析法两阶段分析:用户故事、链路和边界分析。
前3W描写用户故事,用户要什么,为什么要?举个例子,我作为采购小二,需要商品库存为0自动下架,因为有超卖风险,客户会投诉。后面的When、Where、How是链路和边界分析,触发的条件是什么,要实现这个功能需要哪些域参与进来,分别提供什么能力?通过这个分析,获取用户需求,和全链路分工。
4 领域知识提炼,结构化分析APP层至上而下过程分析,模型层自下而上分析相结合。能力下沉保持模型不断演进,能力下沉标准:复用、内聚。5 思考方式的转变领域驱动,在模型阶段不会关注数据设计、不会关注存储、不会关注消息怎么发,业务和技术视角关注点做了分离。
五 商品域实践相关商品域工程架构:
最后,保持模型不断演进!!!
商品域模型更新readme,保持模型不断演进。否则会APP层会越来越大,模型层越来越小,最后头重脚轻,领域坍塌了。
微服务实战技术图谱
由微服务实战课程专家组出品,基于热门的微服务技术栈Spring Cloud Alibaba、Nacos,结合阿里巴巴工程师的一线实战经验,涵盖服务发现、服务配置、服务调用、服务熔断和Service Mesh等相关知识。
点击这里,开始学习吧~
想了解更多内容,请访问: 51CTO和华为官方战略合作共建的鸿蒙技术社区 https://...
溢价 域名 的续费价格如何?通常来说,因为溢价域名的价值高于普通域名,所以溢...
基本介绍 给定 n 个权值作为 n 个叶子节点,构造一颗二叉树,若该树的带权路径长...
背景 我们知道 如果在Kubernetes中支持GPU设备调度 需要做如下的工作 节点上安装...
本文转载自微信公众号「bugstack虫洞栈」,作者小傅哥 。转载本文请联系bugstack...
TIOBE 公布了 2021 年 3 月的编程语言排行榜。 本月 TIOBE 指数没有什么有趣的变...
前言 统计科学家使用交互式的统计工具(比如R)来回答数据中的问题,获得全景的认...
本文转载自公众号读芯术(ID:AI_Discovery)。 这一刻你正在应对什么挑战?这位前...
在Python开发过程中,我们难免会遇到多重条件判断的情况的情况,此时除了用很多...
近几年,互联网行业蓬勃发展,在互联网浪潮的冲击下,互联网创业已成为一种比较...