首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

在CQRS中,我的阅读方应该返回DTO还是ViewModels?

在CQRS(命令查询职责分离)架构中,阅读方(查询)应该返回ViewModels。

CQRS是一种将命令(写操作)和查询(读操作)分离的架构模式,它可以帮助提高应用程序的可扩展性和性能。在CQRS中,查询方的主要目的是从数据存储中获取数据并将其呈现给用户。

ViewModels是一种用于表示数据的模型,它们通常包含一组属性,这些属性可以直接映射到用户界面(UI)组件。在CQRS中,使用ViewModels可以确保查询方返回的数据与UI组件之间的紧密耦合,从而提高应用程序的可维护性和可扩展性。

另一方面,DTO(数据传输对象)是一种用于在不同层次或模块之间传输数据的对象。DTO通常包含一组属性,这些属性可以在不同的层次或模块之间传输,而不需要考虑它们如何在UI中呈现。

因此,在CQRS中,使用ViewModels可以更好地满足查询方返回数据与UI组件之间的紧密耦合需求,从而提高应用程序的性能和可维护性。

推荐的腾讯云相关产品:

  • 腾讯云云巢(TKE):一种基于Kubernetes的容器管理平台,可以帮助用户快速构建、部署和管理微服务应用程序。
  • 腾讯云Serverless架构:一种基于事件驱动的计算服务,可以帮助用户在不需要考虑服务器基础设施的情况下开发和部署应用程序。
  • 腾讯云API Gateway:一种用于管理API的服务,可以帮助用户快速构建、部署和管理API,并提供安全、稳定和可扩展的API访问。

产品介绍链接地址:

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

将项目使用DDD经典四层架构重构后,如何采用CQRS解决查询问题

并不推荐大家使用四层架构,而更喜欢《领域驱动设计(Thoughtworks洞见)》这本书中DEMO架构风格) 作为初学者,尝试将新项目架构改为DDD四层架构后,遇到很多问题,性能问题是一面,另一也一直思考如何优雅实现查询...,一次请求,要么是作为一个“命令”执行一次操作,要么作为一个”查询“向调用返回数据,两者不可能共存。...经典四层架构,由应用层专门一个类负责将聚合根转为读模型实体(这里是DTO),也就是将DO转为DTO采用CQRS后,Order聚合根为写模型,OrderRepresentation为读模型,对应...笔者采用是极客时间《DDD实战课》推荐经典四层架构,应用读模型还是使用DTO,toRepresentation由assembler(装配工)完成。...,并且不需要再作转换就可以响应给调用,这里读模型相当于DTO

2.7K20

从单体架构迁移到 CQRS 后,觉得 DDD 并不可怕

为了实现读 / 写分离,左边写路径,客户端向后端发送 DTO,对数据库进行 CUD(创建 / 更新 / 删除)操作,后端处理完成后向客户端返回表示成功 Ack 或表示失败 Nak。...唯一区别是写路径上用消息代替了 DTO。消息包含动作和数据,而不是像 DTO 那样只包含数据本身。因此,我们可以消息携带特定域动作,使后端更容易识别每个动作,并有一个相应域实现。...在这个阶段,CQRS C 出现了,消息就是一种命令。然而,可扩展性问题仍未得到解决。 另外,虽然我们简化了 DTO,改为使用消息进行通信,但在读路径上我们仍然需要 DTO还是以社交媒体为例。...读取时,客户端需要 DTO,所以后端可以在读路径上做一些专门针对读取优化,比如从原来域对象预先生成 DTO,并将 DTO 存储专门数据库以供读取。...写应该专注于持久化,各种读视图不应该在写路径上处理。但是,读路径上只有读,谁该准备那些读视图? 因此,完整解决方案是这样: 左边写路径和右边读路径已经 CQS 部分介绍过了。

80540

Avalonia项目中使用MediatR和MS.DI库实现事件驱动通信

Request 消息 MediatR ,有两种类型:IRequest 返回一个T类型值。IRequest 不返回值。...这节直接复制MediatR .NET 应用实践 - 明志唯新 (yimingzhi.net),大家应该可以学到些什么:软件开发发展到今天,模式和理念不断架构刷新:从分布式到微服务,再到云原生...实施一个完美的 DDD 还是有难度,现实奋战一线 CRUD 程序员还是不少。那么 CRUD 和 DDD 之间我们是否还有缓冲区呢?...微软官方文档对此做过如下陈述:CQRS 命令和查询责任分离数据存储读取和更新操作分离模式。 应用程序实现 CQRS 可以最大程度地提高其性能、可伸缩性和安全性。...命令可以放置队列中进行异步处理,而不是同步处理。查询从不修改数据库。 查询返回 DTO 不封装任何域知识。

12110

手撸一套纯粹CQRS实现

关于CQRS实现上有很多差异,这是因为CQRS本身很简单,但是它犹如潘多拉魔盒钥匙,有了它,读写分离、事件溯源、消息传递、最终一致性等都被引入了框架,从而导致CQRS背负了太多混淆。...理解是,它分离了读写,为读写使用不同数据模型,并根据职责来创建相应读写对象;除此之外其它任何概念都是对CQRS扩展。...public interface ICommand { } 与Command对应有一个CommandHandler,Handler定义了具体操作。...) { this.Dto = dto; } public CreateBookDto Dto { get; set; } } 不知道这里直接使用DTO对象来初始化是否合理...该实例完整代码github上,感兴趣朋友请移步>>https://github.com/qifei2012/sample_cqrs 如果代码中有错误或不合适地方,请在评论中指出,谢谢支持。

56510

从单体架构迁移到 CQRS架构

为了实现读 / 写分离,左边写路径,客户端向后端发送 DTO,对数据库进行 CUD(创建 / 更新 / 删除)操作,后端处理完成后向客户端返回表示成功 Ack 或表示失败 Nak。...通常, restful API ,2xx 表示成功,4xx 表示失败。右边读路径只是通过读请求来获得相应 DTO。 再从客户端角度来说下 DTO 含义。...在这个阶段,CQRS C 出现了,消息就是一种命令。然而,可扩展性问题仍未得到解决。 另外,虽然我们简化了 DTO,改为使用消息进行通信,但在读路径上我们仍然需要 DTO还是以社交媒体为例。...读取时,客户端需要 DTO,所以后端可以在读路径上做一些专门针对读取优化,比如从原来域对象预先生成 DTO,并将 DTO 存储专门数据库以供读取。...写应该专注于持久化,各种读视图不应该在写路径上处理。但是,读路径上只有读,谁该准备那些读视图? 因此,完整解决方案是这样: 左边写路径和右边读路径已经 CQS 部分介绍过了。

42320

浅谈命令查询职责分离(CQRS)模式

这里面很重要一个问题是,系统读写频率比,是偏向读,还是偏向写,就如同一般数据结构查找和修改上时间复杂度不一样,设计系统结构时也需要考虑这样问题。...并且系统演化能够保持高度灵活性,能够防止出现CRUD模式,对查询或者修改某一进行改动,导致另一出现问题情况。 逻辑清晰,能够看到系统那些行为或者操作导致了系统状态变化。...整个数据管理场景特定模块CQRS可能比较有用。但是在有些地方使用CQRS会增加系统不必要复杂性。...四 CQRS与Event Sourcing关系 CQRS,查询方面,直接通过方法查询数据库,然后通过DTO将数据返回。...实际应用,这一块就是直接对DB进行查询,然后通过DTO对象返回,这个DB可能是应对特定场景报表数据库,这样可以提升查询性能。

1.9K40

DDD-CQRS能解什么问题

事件源不是必须项, 读写分离 如果一个方法修改了对象状态,就是一个命令,不应该返回数据 阻抗:创建资源时候,不是要返回资源id吗(这个不是重点可以忽略) 如果一个方法返回了数据,该方法就是一个查询...,不应该直接或间接修改对象状态 阻抗:现在有些方法查询时候进行了懒删除 CQRS期望解决问题 类似懒删除这种导致数据不一致,难以排查问题 使用同一个领域对象来进行数据读写可能会遇到资源竞争情况...遵循聚合根定义,必须与对象组合区分开,对象组合考虑用DTO或者其他 我们再来回顾下聚合根。...边界内内容具有一致性:一个事务只修改一个聚合实例。如果你发现边界内很难接受强一致,不管是出于性能或产品需求考虑,应该考虑剥离出独立聚合,采用最终一致方式。...像商品详情页这种应该使用DTO来组合。

98010

DDD落地之仓储

至于应用仓储选型是mybatis还是jpa,文中会进行分析,请各位仔细阅读本文。...虽然贫血模型有很大缺陷,但是我们日常代码见过99%代码都是基于贫血模型,为什么呢?...接口名称不应该使用底层实现语法 定义仓储接口,接口中有save类似的方法,与面向集合仓储不同点:面向集合仓储只有新增时调用add即可,面向持久化无论是新增还是修改都要调用save 出参入参不应该使用底层数据格式...而往往功能迭代过程,数据修改逻辑还是复杂,因此建模也都是针对于增删改数据而言。 那么查询数据有什么原则吗? 构建独立仓储 查询仓储与DDD仓储应该是两个方法,互相独立。...它明确表明聚合所必需数据操作。 仓储用于管理单个聚合,它不应该控制事务。 ORM框架选型迁移过程不可决定性因此,可以嫁接转换器,但是还是优先推荐JPA。

95131

3种CQRS架构模式

简单来说,这个原则是说程序应当要么修改系统(Command),要么返回查询结果(Query),软件应当保持命令与查询分离。...尽管 Martin Fowler 在他 2005 年博客文章也提到,这种分离并非总是可能,一个很好例子是返回一个刚插入记录 id。...单数据库 CQRS 单一数据库CQRS 模式没有正式名称,Mattew Renze 在他课程Clean Architecture 中将其命名为单一数据库 CQRS也选择这个命名。...双数据库 CQRS “双数据库”方式,我们需要两个数据库,一个用于写操作,一个用于读操作。命令端使用针对写操作优化数据库。查询端使用针对读取操作优化数据库。...与前面两种方式相比,事件源存储数据思路完全不同。 事件源方法,我们并不只存储实体的当前状态,而且将实体发生每一个状态作为快照来存储。

34520

一文带你落地DDD

2.4.3.命令和查询职责分离--CQRS 一个对象一个方法修改了对象状态,该方法便是一个命令(Command),它不应该返回数据,声明为void。...实现,转换内部模型和外部模型,调用pay接口,返回内部模型dto 将原先业务调用rpc地方改成adapter 单测对比rpc和adapter,保证正确性 3.4.3....至此,原biz里大多数类已迁移完成。 四.迁移过程可能存在疑问 迁移过程中一定会存在或多或少不清楚地方,这里分享一下迁移过程遇到问题。...设想一下,你现在需要调用rpc接口,返回字段有100,你要取其中50个字段。隔了一段时间,调用改了接口逻辑返回,数据被包含在实体内。而你调用这个接口地方特别多,改动就很大了。...8.查询逻辑单独开设一个repository,还是可以聚合根仓储,划分依据是什么 单独开设一个仓储。

64120

整洁架构、DDD 和 CQRS 简介

在这篇文章,Bob 大叔强调了所有前身架构和清洁架构都具备五个品质: 框架独立性:架构与第三框架解耦。 可测试:该架构易于编写单元测试。...查询通过 DTO 将数据返回到表示层。 修改系统高级操作不应返回数据。这些应该会产生副作用,修改系统状态,然后完成。这些被称为命令。...在实践,命令可能会返回一小部分元数据,例如新创建实体 ID,但仅此而已。命令也可能返回 ack/nack 响应。 命令执行另一个结果可能是错误条件,在这种情况下,命令应该抛出异常。...返回 DTO属性结构接近于第一范式,因为数据可能会从非规范化数据库查询返回,并且返回 DTO 结构通常会匹配用户屏幕或某些可由用户使用规范模型任何客户。...最后,研究过大多数专家都同意 CQRS 可以不使用事件溯源情况下提供巨大好处。这是建议您谨慎行事另一个领域,因为这些高级模式不适合胆小的人。

2.9K20

科普 | 简述3种CQRS架构模式

简单来说,这个原则是说程序应当要么修改系统(Command),要么返回查询结果(Query),软件应当保持命令与查询分离。...尽管 Martin Fowler 在他 2005 年博客文章也提到,这种分离并非总是可能,一个很好例子是返回一个刚插入记录 id。...单数据库 CQRS 单一数据库CQRS 模式没有正式名称,Mattew Renze 在他课程Clean Architecture 中将其命名为单一数据库 CQRS也选择这个命名。 ?...双数据库 CQRS “双数据库”方式,我们需要两个数据库,一个用于写操作,一个用于读操作。命令端使用针对写操作优化数据库。查询端使用针对读取操作优化数据库。 ?...有多个为读优化数据存储。 但在另一面,这种方式实现很复杂,如果你不能从其中受益,那么用这个模式可能适得其反。 小结 CQRS 真正威力在于可以对写和读操作进行不同优化。

1.1K10

耿大侠 Diss国外架构师文章《From CQS to CQRS

似曾相识 最近在InfoQ上看到一篇谈论命令模式与CQRS架构译文《From CQS to CQRS》(建议先阅读此文,本文会针对该文一些观点进行探讨),文章从命令模式谈起,然后提出了命令模式升级版...应该说两者是因为遵循了同样OO设计准则才得到了如此高度一致,可见优雅设计都是相似的,模式之所以成为模式是有必然性。 命令模式“错”了吗?...然而文章对命令模式diss是站不住脚,因为即使按照作者推荐方式将所谓变化部分(即“数据”)抽离到一个DTO调用端依然需要实例化它,为其设定各种参数,这些参数天然就是执行业务前提,无论采用何种设计...,作为下达命令“把要干的事情讲明白”是最起码“份内事”,所以命令类构造函数上传递参数和剥离到一个单独DTO包裹数据没有任何本质区别,后者做法反而有“从富领域模型向贫血领域模型开倒车...而另一面,人们也认识到命令模式具有广泛适用性,具备更高级别的架构模式扮演核心角色能力,但是将命令模式提升到更加通用和完备层面还需要解决以下一些问题: 1.

29330

译《领域驱动设计之PHP实现》架构风格(

主要目的是向用户UI层呈现模型,同时模型每次更新后刷新UI呈现形式。一般来说,视图层接收对象 – 通常是一个数据传输对象(DTO)而不是模型层实例 – 从而收集被成功呈现所有必需信息。...为什么要创建一个 DTO 而不是把模型实例直接交给视图层? 简短来说,还是关注点分离。让视图层方便直接使用模型实例将导致视图层与模型层间紧耦合。...以 MVC 为例,先前例子PostRepository类应该放在领域模型当中。...当这些技术被滥用时,对 UI 视图层构建将变得非常痛苦。我们应该权衡是该用应用服务返回领域实例还是某些 DTO 。...命令查询分离 提出一个问题不应该改变对应答案 – Bertrand Meyer 这种设计原则提出每个方法应该要么是执行动作命令,要么是返回数据给调用者查询,而不是两者都是 – 维基百科 CQRS谋求一种更为激进关注点分离

90530

程序员除了会CRUD之外,还应该知道什么叫CQRS

阅读本文约需要5分钟 今天主要跟大家分享一下什么是 CQRS,以及项目中如何去使用。 1....然后通过业务层来处理业务逻辑,将处理结果封装成DTO对象返回给控制层,再通过前端渲染。反之亦然。 ?...首先有几个概念需要介绍一下,CQRS 模式,首先需要有 Command,这个 Command 命令会对应一个实体和一个命令执行类。...除此之外,CQRS 还可以用在任务调度模块,不同任务可以包含不同 Command,实际运用是非常广泛。 5.... CQRS ,所有的涉及到对 DB 操作都是通过发送 Command,然后特定 Command 触发对应事件来完成操作,也可以做成异步,主要看业务上需求了。

48350

从横切到纵切,架构模式CQRS,提高系统进化能力

再谈表现力 领域设计:聚合与聚合根聊到了表现力问题,「数据设计」表现力要弱于「对象设计」!相对应,其实「数据展现」表现力也是弱于「对象设计」! 我们还是以订单来举例!...会对该事件进行处理,比如处理成便于展示模型,存储到ReadDB 客户端可以对服务端发送查询,服务端直接从ReadDB获取数据,构建QueryModel返回 这又什么优势呢?...对于普通分层架构来说,保存订单时需要一个DTO用于存储相关信息,然后转成多个对应Model来进行持久化;而查询订单时候,你需要查询出多个Model,然后组装成另一个DTO来存储查询信息,因为展示时候可能要展示更多信息...那存在读库数据结构就可以完全按照展示逻辑来优化,比如:可以有一张订单展示表,表包含了买家信息和卖家信息。展示时,直接查询这张表就可以了,不需要和用户表进行关联查询,提高了数据读性能。...当需要对ReadDB数据进行恢复操作时,可以通过命令重演方式来恢复。 不过你应该发现问题了,命令重演方式性能上有问题。所以我们可以参考Redis,使用快照+事件溯源方式来存储。

87120

微服务架构下如何解耦,对于已经紧耦合下如何重构?

简单来讲,消息集成,异步,彻底解耦,消息发布订阅,事件链是EDA整个架构核心。但是EDA包括CEP复杂事件处理,使用时候首先还是应该了解清楚其和传统流程驱动在业务分析方法上区别。...这些都是复杂事件分析必须考虑内容之一。 ? 从EDA事件驱动到CQRS ?...CQRS,查询方面,直接通过方法查询数据库,然后通过DTO将数据返回,这个方面的操作相对比较简单。...命令查询职责没有分离时候,可以看到一面是模型本身扩展性受到影响,另外一面是原有的领域模型本身偏重,而且Entity实体本身也通过完整DTO对象进行传输,这样一些特殊只需要更新或查询个别字段时候...第二种即是只需要输入客户编码,微服务A返回最早信用评级。 对于后者就是我们常说粗粒度接口或领域服务,服务间交互应该以领域服务和粗粒度服务为主,避免掉完全数据库表CRUD类服务接口。

1K20

程序员除了会CRUD之外,还应该知道什么叫CQRS

然后通过业务层来处理业务逻辑,将处理结果封装成DTO对象返回给控制层,再通过前端渲染。反之亦然。 ?...CQRS 简单实现 说了这么多,该怎么实现呢?我们以上面提到第一种方式为例:代码层面实现分离,数据库共享。这种方式企业里也非常实用。...除此之外,CQRS 还可以用在任务调度模块,不同任务可以包含不同 Command,实际运用是非常广泛。 5.... CQRS ,所有的涉及到对 DB 操作都是通过发送 Command,然后特定 Command 触发对应事件来完成操作,也可以做成异步,主要看业务上需求了。...最后,希望阅读完本文,能对你有所帮助。

73330

命令和查询责任隔离(CQRS)模式

然而,更复杂应用程序,这种方法可能变得笨拙。例如,在读取端,应用程序可能执行许多不同查询,返回具有不同形状数据传输对象(dto)。对象映射可能变得复杂。...解决方案 CQRS地址将读写分离到单独模型,使用命令来更新数据,使用查询来读取数据。 命令应该基于任务,而不是以数据为中心。...查询返回不封装任何域知识DTO。 然后可以隔离模型,如下图所示,尽管这不是绝对要求。 ? 拥有独立查询和更新模型可以简化设计和实现。...读取模型没有业务逻辑或验证堆栈,只返回一个DTO以便在视图模型中使用。读模型最终与写模型保持一致。 必须将数据读取性能与数据写入性能分开调优,特别是当读取数量远远大于写入数量时。...与其他系统集成,特别是与事件源结合,其中一个子系统时间故障不应该影响其他子系统可用性。 这种模式不推荐什么时候使用当: 域或业务规则很简单。

94220

笔者实战DDD过程遇到问题与思考总结

最令人头疼代码 实战DDD过程,我们编写最多代码无疑就是DO(聚合根)转DTO(读模型)以及DO转PO(映射到数据库表)和PO转DO转换器代码。...基于这些场景就需要将聚合根转为PO再调用对应表DAO存储到数据库。 为什么需要将DO转DTO?...采用CQRS就可以直接使用DAO查询,将查询结果直接映射为DTO响应,绕过了聚合根,笔者将其称为“零拷贝”,没错,与内存零拷贝是相似的概念。...但这需要不少成本,并且项目初期,也没有这方面的预算。 没有分析型数据库情况下,我们如何实现CQRS呢?...每次看对书中理论理解程度都不一样,第一次看有些理论理解得很模糊,实战过后再次阅读就都清晰了。

3.7K30
领券