在一个演示项目中，我将其作为一个概念证明，我发现自己有很多重复的DTO和字段。例如，考虑到代表项目或库存的1个根对象，我将拥有以下类和属性
所有这些对象都是将我的应用程序分离为传统的Domain，Application，Presentation图层的结果。
您如何管理所有这些重复？像AutoMapper这样的工具以及它们之间进行转换的帮助，但是如果我想在Item中添加一个新属性，我将不得不更新所有这些模型。
由于域模型可能与应用程序读取模型不完全相同，因此我理解需要单独定义，但这很快就会成为维护的噩梦。
答案 0 :(得分：1)
查尔斯，
可以帮助您摆脱一些重复的方法可能如下：
不要在实体上添加公共属性。当您使用事件源时，将通过重播与相关实体关联的事件来恢复实体的内部状态。并且实体外部的任何人都不应该知道实体的重建状态是如何表示的 - 一系列私有字段，字符串对象数组等等。毕竟，你可以选择没有其状态的内部表示，但是通过每次只重放事件来实现所有行为（所有方法）:)所以，在一个极端，你可能有1个单个字段entity = 一系列事件。
项目阅读模型和响应DTO ...让它们成为相同的东西！在使用 cqrs 时，也就是说，您已经将读取模型与写入模型隔离开来，没有必要制作烤宽面条超出应用程序的读取端。在读取端具有最小数量的抽象层是可以的。 读取模型已经没有行为，只是数据。它是从事件构建的DTO，被持久化到具有（或多或少）非规范化模式的数据存储中，并且在用户请求时，从存储中检索并在UI上呈现。纯 数据 将 转移 从一个地方转移到另一个地方。但是，如果由于某种原因，除了来自读取模型对象的数据之外，还必须返回最终用户（人或机器）的某些其他数据，请应用基本对象组合。将两个或多个无行为对象组合成一个这样的对象。并将后者发送到电线上。
谈到合成，你甚至可以在共享库中定义一个（值）类型，如 ItemDescriptor [Code，Description，Weight]，并在定义 CreateItem时使用它命令， ItemCreated 事件，读取模型，查询请求对象等。如果您使用的语言支持mixins，那么混合 ItemDescriptor in :)否则，可能会应用基本构图。
此外，＆＃34;维护噩梦＆＃34; 可以在某种程度上得到改善if packaging by feature would be used instead of packaging by layer.
另外，也许this post可能会有所帮助。