我正在研究一个小示例应用程序，以学习CQRS和事件源的概念。我有一个Basket汇总和一个Product应该独立工作的汇总。
这是一些伪代码来展示实现
Basket { BasketId; OrderLines; Address; }
// basket events
BasketCreated { BasketId; }
ItemAdded { BasketId; ProductId; Quantity }
AddItemSucceeded { BasketId; ProductId; Quantity }
AddItemRevoked { BasketId; ProductId; Quantity }
ItemRemoved { BasketId; ProductId; Quantity }
CheckedOut { BasketId; Address }
Product { ProductId; Name; Price; }
// product events
ProductReserved { ProductId; Quantity }
ProductReservationFailed { ProductId; Quantity }
ProductReservationCancelled { ProductId; Quantity; }
命令与事件非常相似，使用命令性名称而不使用过去式。
现在，这些独立工作就可以了。我发出一个命令AddItem，它ItemAdded在Basket聚合上创建一个事件，该事件完成了对“篮子”状态的处理。同样，对于产品，命令和事件也可以正常工作。
我现在想将其组合成一个过程，该过程将是这样的（就发生的命令和事件而言）：
流程经理将执行以下操作：
on BasketCreated: CreateShoppingProcess
on ItemAdded: ReserveProduct
on ProductReserved: SucceedAddingItem // does nothing, but needs to be there so that the basket knows it can check out
on ProductReservationFailed: RevokeAddItem
on RemoveItem: CancelProductReservation
on Checkout: CreateOrder // create an order and so on...
我找不到明确答案的问题是：
- 我是否需要坚持流程经理？看起来像我，但我不确定
- 如果这样做，则需要为流程管理器保存事件。但是，它正在监听的事件与聚合相关。是否向其中添加进程ID？我是否有仅针对流程经理的单独事件？如何做到这一点并尽可能保持干燥
- 我怎么知道这些
ProductReserved活动是为了什么？可以在BasketId上面也可以，还是泄漏信息？ - 如何保持事件之间的关系，如何知道
ItemAdded哪个ProductReserved事件产生了？我会经过EventId吗？这似乎很奇怪... - 我应该将其实现
Basket为流程管理器而不是简单的集合吗？
经过更多研究后，我得出以下结论：“传奇”是一种保留自己的事件并从外部监听事件的东西。基本上，它是一种聚合，也可以对自己的小世界之外发生的事件做出反应。
流程管理器处理来自外部的事件并发出命令。可以从共享相同标识符（如correlationId）的聚合事件中重建事件的历史记录。
似乎您正在尝试在系统中编码一个正式过程，以解释由一系列命令构成的现有非正式用例。这样做，看起来您正在创建除现有命令和事件之外的许多冗余命令和事件。那是你的意图吗？将事物形式化为代码流程的背后的业务需求是什么？您域中的哪些内容要求您确定此过程以及将其作为完整概念的原因？
—
guillaume31
这是一个完全组成的项目，目的是学习如何使两个相对独立的聚合一起工作。因此，实际上并没有真正的“业务需求”，并且我正在尝试尽可能避免这些命令和事件中的冗余。因此，与流程管理器的混乱，因为似乎不应重复聚合已处理的内容。但是，我需要以某种方式在这两个聚合之间保持联系。似乎使用因果关系和关联可能会有所帮助，但我需要尝试一下。
—
伊万·平塔尔