广州响应式网站建设,南京网站开发南京乐识权威,网站微信支付怎么开通,创app开发 杭州app开发公司前言 上一篇#xff1a;从领域驱动到模型驱动中我们讨论到#xff0c;领域驱动设计的核心思想是保持业务-模型-代码的一致性#xff0c;模型作为沟通业务和代码的工具#xff0c;至关重要#xff0c;今天这篇文章就来讨论DDD中建模的一些思考和方法。 什么是建模 虽然看…前言 上一篇从领域驱动到模型驱动中我们讨论到领域驱动设计的核心思想是保持业务-模型-代码的一致性模型作为沟通业务和代码的工具至关重要今天这篇文章就来讨论DDD中建模的一些思考和方法。 什么是建模 虽然看到这篇文章的读者都是IT从业人员大家都知道建模是怎么回事但我还是想先对建模这件事讨论几句我理解的建模是对业务中数据流的合适描述。业务是公司的经营活动但是在软件工程范畴中当业务人员找到开发说要开发个系统来管理业务的时候其本质是需要一个能管理业务中数据的系统。因为软件系统唯一能处理的只有数据它不可能做到把货物从A运到B类似的事情但它可以通过把“货物从A运到B”这件事情通过数据的方式传递给合适人去完成。因此我们构建软件系统时唯一关注的是如何处理业务中的数据。业务中的数据具有历史性即其会随着业务的流转而变化衍生出新的数据。将业务全周期中的所有数据视为一个集合不同的业务阶段、业务操作、业务视角都是关注集合中部分数据并筛选出来形成一个子集。例如电商场景中一个完整的订单流程包含用户浏览商品、下单、付款、物流等阶段包含商品名称、用户地址、付款渠道、物流明细等数据。但在不同的业务阶段不同的业务角色只关注部分数据但因为各参与方都使用同一套系统同一套数据因此系统还要关注模型间数据的流转路径。将数据集合进行划分并描述其变化路径这就是建模。 什么算好的建模 模型包含数据和行为。模型本质上是一个集合是为了最大限度满足使用方信息完备要求并且使得系统管理代价最小的平衡结果。这里说得系统管理代价实际上是指数据规模、信息密度超出人脑处理信息上下文的容量后带来的复杂度急剧上升从而无法做出有效、正确决策使得系统和业务的一致性越来越低使软件系统在错误的道路上越走越远。因此建模的评判标准有三个1、和业务保持一致2、信息完备3、管理代价最小。 “和业务保持一致” 这里就是DDD中提倡的“共同语言”创建的模型应该能和业务中的概念术语一一对应不能自己创造、篡改、臆想出一个模型应该是业务流程中确实存在、需要的数据子集。数据的流转应该符合业务实际中的数据变化实际而不能为了技术、性能、方便等理由而强行创建出一条数据流。 “信息完备”是指应该从业务流程出发将上下文需要的数据都在模型中体现。如果某个数据在节点3处使用而它是在节点1出产生的那么它就应该沿着节点1-节点2-节点3的路径流转而不是在节点3处再去节点1中获取。 “管理代价最小”主要指的是系统复杂度要最小复杂度的度量有两个指标模型数量和模型关系且模型关系对复杂度的影响远大于数量。这里说得复杂度仍然是描述开发人员对系统的理解、掌握、改造时要处理的信息大小。为什么说关系对复杂度的影响远大于数量呢 一本新华字典的体量远大于一本红楼梦小说但理解红楼梦的复杂度远大于新华字典。因为字典中收录的汉字都是独立的前后并无强烈关联。但红楼梦中包含的人物、故事纷纭复杂想要读懂甚至修改红楼梦需要大师级的文学素养。因此建模时我们应该着力避免模型间的关系必要时可以用模型的数量来规避关系。 建模方法 由于DDD追求建模和业务的一致性且愿意使用模型的数量来置换关系以追求系统的复杂度降低DDD中常采用的建模方法是CQRSCommand Query Responsibility Segregation命令查询职责分离和命令-事件模型。CQRS将系统的功能分为两类写操作和读查询每个写操作视为一个命令是真正的业务流程只针对写操作建模。而读请求不会对系统造成更改可以直接从数据层取数据组装返回。大部分系统属于写少读多运用CQRS的方式会大大降低建模难度。 命令-事件模型将系统中的写操作分类两部分命令、事件命令由外部触发其携带了上下文数据命令通过执行对系统的状态数据产生了变更由此产生了事件该事件携带了一些数据可能被系统中某些部分关注从而做出反应这些反应通常也会使用执行命令的方式完成由此循环往复把系统中的所有写操作使用命令-事件模型描述清楚。 例如用户选择商品后点击下单对于系统来说用户触发了一个命令该命令包含了用户和商品等上下文数据系统需要执行该命令。通过某个命令执行器将“创建订单”命令执行完毕后系统中将会保存一份订单数据还需要广播一个事件“订单已创建”其将包含已创建订单的关键信息。用户积分管理业务关注“是否有订单创建”这件事通过合适的方式监听到“订单已创建”事件将自己要进行的业务操作也封装成一个命令通过专有的命令执行器处理自己的业务。 为何命令-事件模型适合DDD 命令-事件模型只是一种建模方法其可以脱离DDD使用但因为其具有的几个特点使得其非常适合应用在DDD中。 1、命令-事件模型只针对写操作建模符合CQRS思想。 2、命令-事件的万能句式是xxx操作触发了yyy事件发生yyy事件时做zzz操作。使用这样的句式能将业务流程、内里变化描述得非常清晰而且只需要命令、事件两类模型即可完成建模意味着模型和业务保持一致非常容易。 3、由于建模结果容易理解且具有很强的业务表达能力意味着使用代码描述模型将会非常容易因此更能保证代码和模型的一致性。 4、命令-事件天然具有对应关系而事件到命令可通过命令总线方式隔离、解耦使得系统中模型间关系减少大大降低了系统复杂度。 总结 本篇主要分析DDD中对建模的一些要求建模首先要保证和业务的一致性齐次通过减少关系来降低结果复杂度。CQRS命令-事件模型是目前DDD中的操作性强、适应范围广的符合DDD核心要求的可落地建模方法。这里推荐一个B站视频Java8 到 .NET8 - 掌握这个模型你就能设计一切详细介绍了如何使用命令-事件模型进行建模的细节。