如何在 DDD、事件溯源中正确设计聚合

Question

假设我想做一个电子商务系统。我这里有 2 个聚合 ProductAggregate 和 UserAggregate。产品聚合包含productId、价格。用户聚合包含userId和余额。问题是，在事件溯源中我们不应该依赖读取模型，因为可能存在最终一致性问题。好吧，我想我们应该依赖命令模型，对吗？但这两个命令模型是不同的。我从其他地方读到他们告诉我聚合应该只依赖于它的状态。假设用户想要购买产品，我必须检查他是否有足够的余额，为此我需要知道产品的价格。所以不允许读取模型，不允许聚合查询。我在这里有什么选择？

const ProductAggregate = {
    state: {
        productId: "product-1",
        price: 100
    }
}

const UserAggregate = {
    state: {
        userId: "userId-1",
        balance: 50
    },
    handlePurchase: ({ userId, productId }) => {
        // todo I got productId from the client, but how can I retrieve its price ?
        if (this.state.balance < price) {
            throw "Insufficient balance bro."
        }
    }
}

所以我认为这一定是我糟糕的聚合设计，使得 UserAggregate 需要来自其上下文之外的状态。那么在这种情况下，我如何正确设计用户和产品的聚合。

编辑：

我整天都在思考解决方案，并想出了这种方法。因此，我没有将购买命令放入 UserAggregate 中，而是将其放入 ProductAggregate 中，并将其命名为 OrderProductCommand ，这对我来说有点奇怪，因为产品本身无法创建订单，但用户可以（它似乎可以工作，我什至不知道？）。因此，通过这种方法，我现在可以检索价格并发送另一个命令 DeductBalanceCommand ，该命令将从用户中扣除金额。

const ProductAggregate = {
    state: {
        productId: "product-1",
        price: 100
    },
    handleOrder: ({productId, userId}) => {
        await commandBus.send({
            command: "handleDeduct",
            params: {
                userId: userId,
                amount: this.state.price
            }
        })
        .then(r => eventBus.publish({
            event: "OrderCreated",
            params: {
                productId: productId,
                userId: userId
            }
        }))
        .catch(e => {
            throw "Unable to create order due to " + e.message
        })
    }
}

const UserAggregate = {
    state: {
        userId: "userId-1",
        balance: 50
    },
    handleDeduct: ({ userId, amount }) => {
        if (this.state.balance < amount) {
            throw "Insufficient balance bro."
        }

        eventBus.publish({
            event: "BalanceDeducted",
            params: {
                userId: userId,
                amount: amount
            }
        })
    }
}

使用这种方法是否正确？这对我来说有点奇怪，或者这可能只是 DDD 世界中的一种思维方式？

附：我添加了 javascript 标签，这样我的代码就可以有颜色并且易于阅读。

Answer 1

首先，关于你的句柄，你并不愚蠢:)

几点：

• 在许多情况下，即使存在最终一致性，你也可以查询读取模型。如果您拒绝在读取模型中显示挂起的更新时本应接受的命令，则通常可以重试该命令。如果您接受本来会被拒绝的命令，则通常可以在事后应用补偿操作（例如，订购实物产品和交付该产品之间的延迟）。

• 有一些有用的模式。一种是传奇模式，您可以在其中对购买过程进行建模。您可能拥有与“用户 A 尝试购买产品 X”相对应的聚合，而不是“用户 A 购买产品 X”，该聚合验证并保留用户 A 能够购买 X 并且 X 能够被购买。

• 每个具有聚合的写入模型都意味着该聚合存在一个足够一致的读取模型。因此，我们可以针对写入模型定义查询或“只读”命令。 CQRS（IMO）不应被解释为“不要查询写入模型”，而是“在尝试优​​化读取的写入模型（无论是易用性、性能等）之前，请充分考虑使用读取来处理该查询model”：即，如果您正在查询写入模型，您就放弃了一些抱怨查询缓慢或困难的权利。根据您实现聚合的方式，此选项可能很容易实现，也可能不容易实现。