网站域名怎么修改,免费定制开发软件,佛山建设网站公司吗,百度seo发帖推广简介#xff1a; DDD是一套方法论#xff0c;实践能否成功#xff0c;不仅仅是个技术问题#xff0c;更是执行贯彻实施的问题。本文将就DDD的基本概念和DDD的实施进行分享。 作者 | 侧帽 来源 | 阿里技术公众号
前言
供应链商品域DDD实践时间不长#xff0c;在实践过程也…简介 DDD是一套方法论实践能否成功不仅仅是个技术问题更是执行贯彻实施的问题。本文将就DDD的基本概念和DDD的实施进行分享。 作者 | 侧帽 来源 | 阿里技术公众号
前言
供应链商品域DDD实践时间不长在实践过程也碰到了不少问题有些找到了答案有些还是在探索中。最近很荣幸受邀在供应链服务与创新团队做了一次分享也想在这里把一些经验和想法分享给大家借此抛砖引玉。
DDD是一套方法论实践能否成功我觉得不仅仅是个技术问题更是执行贯彻实施的问题。
本文内容主要有两部分DDD基本概念和DDD实施。基本概念包括通用语言、分层架构、DDD要素、边界上下文DDD实施包括领域知识提取方法、思考方式的转变在其中会穿插一些商品案例。
一 软件复杂性是什么
在开始DDD前我们应该先回答的一个问题我们为什么需要DDDDDD是复杂软件应对之道所以我们来一起看看软件的复杂度到底在哪里
在阿里两年我感受很深的一个点是我们不能持续交付不断演进的复杂软件所以有1.0、2.0、3.0很多的版本1.0搞不下去了开始2.02.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 边界上下文
边界 域或子域。领域对象在领域内才有确切的含义。出了这个边界不能确保还是这个含义如苹果。语言是有上下文的。在不同的上下文中职责和任务不一样。人有多个角色在家里是爸爸、在公司是小二职责和任务不一样。上下文映射
有了边界那么领域如何输出价值呢一个完全封闭的系统没有任何价值。常用的方式有共享内核防腐层等。防腐层商品上游提供spispi不是直接对外开放领域模型建立一层开放视图。采购域建立防腐层收口商品的变更对本域影响。四 DDD实施
1 DDD实施的挑战
识别和提炼领域知识并体现在模型代码上强调一次“并体现在模型代码上”防腐保持模型不断演进需要持续投入保证DDD贯彻执行。人的转变开发思考方式的转变。2 什么是领域知识
领域知识有分层分类平台通用商业规则是领域模型主要输入商家个性化不能下沉到领域模型层。 3 领域知识提炼需求和链路5W1H分析法
两阶段分析用户故事、链路和边界分析。
前3W描写用户故事用户要什么为什么要举个例子我作为采购小二需要商品库存为0自动下架因为有超卖风险客户会投诉。后面的When、Where、How是链路和边界分析触发的条件是什么要实现这个功能需要哪些域参与进来分别提供什么能力
通过这个分析获取用户需求和全链路分工。 4 领域知识提炼结构化分析
APP层至上而下过程分析模型层自下而上分析相结合。能力下沉保持模型不断演进能力下沉标准复用、内聚。5 思考方式的转变
领域驱动在模型阶段不会关注数据设计、不会关注存储、不会关注消息怎么发业务和技术视角关注点做了分离。 五 商品域实践相关
商品域工程架构 最后保持模型不断演进
商品域模型更新readme保持模型不断演进。否则会APP层会越来越大模型层越来越小最后头重脚轻领域坍塌了。 原文链接 本文为阿里云原创内容未经允许不得转载。
