处理财产重复

时间:2014-08-22 16:40:44

标签: domain-driven-design cqrs event-sourcing

在一个演示项目中,我将其作为一个概念证明,我发现自己有很多重复的DTO和字段。例如,考虑到代表项目或库存的1个根对象,我将拥有以下类和属性

  • CreateItem [代码,描述,重量]
  • 聚合根目录[代码,描述,权重]
  • ItemCreated事件[代码,描述,重量]
  • 项目阅读模型[代码,描述,重量]
  • 查询请求对象[代码,描述,权重,页面,PageSize]
  • 响应DTO [代码,描述,重量]

所有这些对象都是将我的应用程序分离为传统的Domain,Application,Presentation图层的结果。

您如何管理所有这些重复?像AutoMapper这样的工具以及它们之间进行转换的帮助,但是如果我想在Item中添加一个新属性,我将不得不更新所有这些模型。

由于域模型可能与应用程序读取模型不完全相同,因此我理解需要单独定义,但这很快就会成为维护的噩梦。

1 个答案:

答案 0 :(得分:1)

查尔斯,

可以帮助您摆脱一些重复的方法可能如下:

  • 不要在实体上添加公共属性。当您使用事件源时,将通过重播与相关实体关联的事件来恢复实体的内部状态。并且实体外部的任何人都不应该知道实体的重建状态是如何表示的 - 一系列私有字段,字符串对象数组等等。毕竟,你可以选择没有其状态的内部表示,但是通过每次只重放事件来实现所有行为(所有方法):)所以,在一个极端,你可能有1个单个字段entity = 一系列事件

  • 项目阅读模型响应DTO ...让它们成为相同的东西!在使用 cqrs 时,也就是说,您已经将读取模型写入模型隔离开来,没有必要制作烤宽面条超出应用程序的读取端。在读取端具有最小数量的抽象层是可以的。 读取模型已经没有行为,只是数据。它是从事件构建的DTO,被持久化到具有(或多或少)非规范化模式的数据存储中,并且在用户请求时,从存储中检索并在UI上呈现。纯 数据 转移 从一个地方转移到另一个地方。但是,如果由于某种原因,除了来自读取模型对象的数据之外,还必须返回最终用户(人或机器)的某些其他数据,请应用基本对象组合。将两个或多个无行为对象组合成一个这样的对象。并将后者发送到电线上。

  • 谈到合成,你甚至可以在共享库中定义一个(值)类型,如 ItemDescriptor [Code,Description,Weight],并在定义 CreateItem时使用它命令, ItemCreated 事件,读取模型,查询请求对象等。如果您使用的语言支持mixins,那么混合 ItemDescriptor in :)否则,可能会应用基本构图。

此外,"维护噩梦" 可以在某种程度上得到改善if packaging by feature would be used instead of packaging by layer.

另外,也许this post可能会有所帮助。