Question

我被要求将CQRS模式应用于现有项目。如果可能的话，这不应该对使用整数ID的数据库进行任何架构更改。

然而，我所看到的CQRS的每个例子都使用Guids，我的问题是这是使用CQRS的固有要求，还是有一种方法可以适应它。

（我们这样做是为了练习，所以做这样的事情的实用性和实用性并不是问题）。

Answer 1

由于使用CQRS的一个方面是您可以使用它创建（大型）分布式应用程序，而不是UUID，但整数ID可能会损害系统以分布式方式工作的能力。

这里的问题是你需要一个中央计数器，它需要锁定，事务以及你不希望在分布式系统中拥有的所有这些东西。

所以，是的，当然你可以使用整数ID，但就可扩展性而言，这是一个坏主意。如果这对你来说不重要，那么它（可能）仍会有效。

Answer 2

CQRS没有理由要求GUIDS。如果您需要多个写入服务，通常需要GUIDS，但CQRS只是将读取和写入服务（以及两者使用的模型）分开。

Answer 3

CQRS需要guid，因为命令的来源必须独立于任何ID的中央调度。它们很容易生成。如果标准库没有为您提供guid，那么加密库实际上更好。这是我用于Go的内容：

func pseudo_uuid() (uuid string) {

    b := make([]byte, 16)
    _, err := rand.Read(b)
    if err != nil {
        fmt.Println("Error: ", err)
        return
    }

    uuid = fmt.Sprintf("%X-%X-%X-%X-%X", b[0:4], b[4:6], b[6:8], b[8:10], b[10:])

    return
}

虽然将CQRS看作是将系统分成两个系统的方法 - 一个负责状态转换，另一个负责其他一切 - 重要的是要注意CQRS的动机是可扩展性和你构建的抽象依靠中央发送的ID会在您扩展时花费您的重构努力。

使用带CQRS模式的整数ID

3 个答案: