如何在CQRS + Event Sourcing架构中处理Add / Create *命令

我想使用CQRS模式和Event Sourcing来实现我的第一个应用程序。我想知道如何正确处理聚合根的创建。假设有人发送CreateItem命令。应该如何处理？事件ItemCreated应该存储在哪里？作为新项目的第一事件？还是我应该具有某种ItemList实体来聚合所有项目，并且其事件列表仅由ItemCreated事件组成？

乌迪·达汉（ Udi Dahan）建议不要创建聚合根，而应始终使用某种获取方法。但是我如何获取新的东西，当然还没有分配任何ID。我理解背后的想法，并且认为一个新对象是其状态由零个事件组成的对象是很合理的。但是我应该如何使用呢？我的存储库中应该有一个与众不同的方法吗？getNewItem()还是让我的get(id)方法接受Optional<ItemId>？

编辑：经过一段时间的挖掘，我发现使用actor对上述模式进行了非常有趣的实现。作者不是创建聚合，而是从某种具有新创建的UUID的存储库中检索聚合。这种方法的缺点是他允许出现临时的不一致状态。我也想知道如何delete使用这种方法来实现方法。只需将Deleted事件添加到聚合的事件列表中？

据我所知，乌迪（Udi）的帖子中的想法是，没有任何物品可以凭空出现。（几乎）总是存在某些东西，或更具体地说，是某些域操作导致了项目的创建。就像Udi的例子一样，用户实际上是从注册该网站的访问者中诞生的。在这一点上和那个有界上下文中，Visitor是聚合根，它是通过其IP地址检索的。然后，此访问者此时通过称为Register的域操作创建一个新的“项目”，即用户。之前的步骤也是相同的，这是另一个有界上下文：引荐来源网址是AR，它是通过URL检索的，并且具有一个称为BroughtVisitorWithIp的域操作，该访问者是在此处出生的。

Udi在删除方面也写得很好：http : //www.udidahan.com/2009/09/01/dont-delete-just-dont/。主要思想是，您永远不会删除任何内容。后面总是有一个域操作，我们要捕获。就像订单被取消，而不是删除。阅读它，这是一个很好的帖子。

这两个帐户在执行DDD（尤其是事件源）时的要点是，永远不要执行直接的CRUD操作。如果您发现自己确实只需要插入，更新或删除一些数据，并且其后确实没有域操作，那么DDD和Event Sourcing可能不适合该有限上下文。只要一个有限的上下文遵循一个原则，您就可以随意组合这两个对象。这样，CRUD样式的有界上下文可以在数据库中创建某些行，该行成为另一个有界上下文中的一个实体和一个聚合根，您现在可以在其中检索AR而不必创建它。