在阅读了埃文斯和弗农之后，我还有一个基本的问题。我知道，一个实体（实例）当然只能处于一个集合中。但是实体类可以用于多个聚合（类）吗？为了澄清起见，我在课堂上问。其他公式：两个不同的聚合根类（！）可以聚合同一实体类吗？当然，任何实体实例都必须仅属于两个聚合根类之一的一个实例。对于值对象类，这似乎是可能的。至少我的印象是，例如“ money”的值对象类可以用于不同的聚合类型。
在我看到的大多数示例中,命令和事件都表示为类.这意味着您必须使用name属性编写CorrectNameCommand类,并使用name属性编写NameCorrectedEvent类.鉴于在大多数情况下命令和事件都被序列化和反序列化并发送给其他方(编译时类型安全),这个显式类相对于更通用的类有什么优势？
例:
具有Name(表示命令类型)的Command类,应该处理命令的ag的键以及任何其他参数的对象数组或名称/值对.
一个Event类基本相同(也许我们可以将共享部分放在CommandEventBase类中).
命令(和事件)处理程序现在要检查命令(事件)的名称而不是它的类类型,并且必须依赖列表中参数的正确性(就像解串器必须依赖序列化格式是正确的一样) ).
这是一个好方法吗？如果是,为什么不在样本和教程中使用它？如果没有,有什么问题？
DDD中的域模型应该是持久性不可知的.
CQRS要求我在我的阅读模型中为我不想拥有的一切事件发起事件.(顺便把我的模型分成写模型和至少一个读模型).
ES要求我为所有改变状态的事件触发事件,并且我的聚合根必须处理事件本身.
这对我来说似乎并不是非常持久的.
那么如何在没有这种持久性技术对域模型的重大影响的情况下组合DDD和CQRS/ES？
读取模型是否也在DDD域模型中？或者在它之外？
CQRS/ES事件是否与DDD域事件相同？
编辑:
我从答案中取出的内容如下:
是的,对于ORM,域模型目标的实现将与使用ES的实现不同.问题是错误的方式.首先编写域模型对象,然后决定如何持久化(更多事件,如=> ES,更多数据,如=> ORM,......).
但我怀疑你是否能够使用ES(没有对你的域对象进行大的添加/更改),如果你没有做出这个决定,并且使用ORM而不确定它会导致非常痛苦.:-)