CQRS命令构造

Question

我有一个像CQRS命令这

public sealed class RequestRoute 
{ 
    public RequestRoute(string fromAddressName, double fromLatitude, double fromLongitude, string toAddressName, double toLatitude, double toLongitude, string userId) 
    { 
     UserId = userId; 
     ToLongitude = toLongitude; 
     ToLatitude = toLatitude; 
     ToAddressName = toAddressName; 
     FromLongitude = fromLongitude; 
     FromLatitude = fromLatitude; 
     FromAddressName = fromAddressName; 
    } 

    public string FromAddressName { get; private set; } 
    public double FromLatitude { get; private set; } 
    public double FromLongitude { get; private set; } 

    public string ToAddressName { get; private set; } 
    public double ToLatitude { get; private set; } 
    public double ToLongitude { get; private set; } 

    public string UserId { get; private set; } 
} 

我的程序员的直觉告诉我，我应该的因素和FromXXX领域ToXXX进入所谓的“地址”中一个单独的类...但我不确定是否违反了CQRS模式...我见过的所有例子都只使用基本类型作为命令和事件的属性。

Answer 1

对我的钱来说，在这样的重构中没有真正的价值。

书写route.ToLatitude或route.To.Latitude不会在可读性和维护期间更改任何内容。

不过，我的double场更改为decimal（甚至是string），以避免任何问题，同时移动DTO序列化（无论是二进制或没有）不同的平台，设备或架构之间。

Answer 2

模式上，它似乎很好提取一个共同的类型。总的来说，命令一旦发布就不应该改变，所以只要确保地址类型是不可变的（就像原始类型一样）。

可能有一些需要考虑的实现约束条件，即序列化。

Answer 3

我认为这里有一点点混乱。 CQRS只是意味着分开读取和“写入”（行为丰富）模型。 RequestRoute是一个命令，因此是一个消息而不是一个模型。 CQRS可以与消息驱动的体系结构一起使用，但它不是必需的，所以这两个不相关。

在这种情况下，你是对的，FromXXX和ToXXX应该是一个Address类，但这与CQRS无关，所以你没有违反任何规定。

顺便说一句，一条消息应该包含其处理程序所需的所有必需信息，以便您可以在其中放入很多东西，唯一的问题是序列化，如果您知道消息将被保留，但消息不是无论如何，这不仅仅是一个DTO。

Answer 4

命令是面向数据的，而不是面向对象的。它的属性应该主要是原始的。你在这里没有建模任何东西，只是发送平坦的数据。

使用自定义类型强制您将类型发布到每个想要使用这些命令的客户端。这也会阻止你在将来不经过一些麻烦就改变这些类型。

然后就是可升级性：自定义类型越少越简单。

在类似命令和事件的消息中，尽可能合理地使用原语。复制不是这里的问题，你需要低耦合，可串行化，改变容差。

Answer 5

这里提取一个通用类型没有任何问题。大多数情况下，你应该共享模式而不是类型，所以在这方面不会造成问题。

Answer 6

您可以安全地将“To”和“From”重构为一个类。命令是你的域的API，所以只要你可以维护它 - 你应该是好的。

P.S.如果您对事件采购中的事件提出同样的问题 - 答案会更复杂