Domain driven design CQRS/ES更新聚合命令

我目前正在替换应用程序的域层，但必须保留现有的MVVMUI。我们当然想要一个事件存储，但我正在努力解决当前CQRS实现的某些方面

我们有一些复杂的聚合，其中包含多个实体集合和键/值对动态属性。我们现有的UI有一个用于此聚合的大编辑屏幕，我不确定如何构造用于更新的命令

可能的解决办法： 1） 只需在ViewModel中获取聚合，对域模型执行更新，并随命令一起发送（

var command=new SaveAggregateCommand（myAggregate）；

）。这感觉是错误的，因为如果跨序列化边界（没有自定义序列化）传送此内容，则内部事件将不会保留

2） 创建一个复杂的命令对象，该对象包含一个更新属性列表，以及每个集合类型的添加、更新和删除子实体的单独列表。这对于命令处理程序来说是最容易处理的，但感觉非常草率

3） 创建许多命令，这些命令基本上反映了捕获的域模型的事件（在我的场景中最多有38个）。然后，视图模型必须保留一个未提交的命令列表，当用户按下保存按钮时，这些命令将被提交。就像#2一样，这也让人感觉不舒服

---

由于这个集合的（必要的）复杂性，这些解决方案没有一个是正确的。我希望在这个问题上有一些指导。

所以，答案是：我做错了。命令被分解成更易于管理和更具体的部分，农民们欢欣鼓舞。

这听起来像是一个超大规模的集合。你能告诉我们更多关于AR的情况吗？你为什么选择了ES？在这个场景中捕获意图是一个PITA，您可以更改UI吗？更改UI必须稍后进行。这是一个商业决定。AR中的所有东西都需要在那里。它真的不能再被分解了。你可以使用一个大命令，在应用层进行逆向工程。因此，有比执行CRUD更新的命令更多的命令。这些将是分开的。我遇到的问题是，我需要一个事件流来跟踪在遗留UI中一次性保存的一大组数据上的修改。在查看并构建了各种命令之后，事情并不像我想象的那么大和复杂。我最大的命令只有13个属性。感谢您的投入！聚合是否分解为？所有这些命令是否都在同一聚合上运行？是的，超级聚合被拆分为3个聚合。