命令消息——分类设计题

Question

我正在尝试使用事件溯源设计一项服务。一个用例是——当命令到达时，我必须执行一些逻辑并将对象从一种模式转换为另一种模式。现在，"problem" 我面临的是在命令消息的这两个选项之间做出决定：

选项 1：（将模式直接放入命令消息的名称中）

SetToManualModeCommand{
  int val = 22;
}
SetToAutoModeCommand{
  int val = 22;
}
SetToSemiAutoModeCommand{
  int val = 22;
}
SetTo...ModeCommand{
  int val = 22;
}

选项 2：（将模式作为单个命令消息中的枚举）

enum Mode{
  AUTO, 
  SEMI_AUTO, 
  MANUAL;
}

SetToModeCommand{
  Mode mode;
  int val = 22;
}

模式不会经常改变 - 但它们可以改变。如果它们发生变化 - 在选项 1 中，我必须创建新的 class。在选项 2 中，我必须添加一个额外的枚举值。

您看到这 2 个选项中的任何一个 drawbacks/benefits，还是它们更不相同？

Answer 1

作为一般原则 - 使隐含明确。因此，为每个 'mode' 创建一个命令。但老实说，我觉得里面的东西不多。

很明显，您实际做的事情很大程度上取决于您正在构建的系统的上下文。多久引入一次新模式？

但是，我要说的是，您绝对应该为每种模式设置一个事件。

Answer 2

从你给出的上下文来看，我没有看到任何令人信服的论据。我知道你在谈论命令，而不是事件，但请尝试从事件订阅者的角度考虑它。是众数以某种方式发生变化，还是变为特定值的重大事件？换句话说，订阅者是否想要一个包含事件内部详细信息的 ModeChanged 事件，或者一些订阅者只想要 ModeChangedToManual 而其他订阅者只想要 ModeChangedToAuto 等。您可能会考虑您正在使用的事件存储系统以及创建它的难易程度过滤订阅。

每个命令创建一个事件很方便（不是必需的）。如果订阅者更喜欢单个事件，而您有 4 个命令发出该事件，那么系统只会稍微复杂一点，而且这些微小的部分往往会累加起来。如果您有 4 个单独的事件对订阅者更好，那么有 4 个单独的命令。

Answer 3

看看你的代码想要什么。如果命令发送代码是对您的模式进行编码的 switch 语句，并且事件消费代码也是对您的模式进行解码的 switch 语句，那么只需将模式作为 command/event 有效负载发送即可。

如果每种模式的消费代码位于不同的地方 - 那么让每个地方都可以轻松订阅正确的模式 - 为每种模式制作不同的事件。

Answer 4

我的一般做法是不将 classification 作为结构。 class化为数据似乎更容易。

另一个与您的示例类似的示例是不同类型的客户：GoldCustomer、SilverCustomer 或 BronzeCustomer。一段时间后（2-3 年），企业可能会决定添加 PlatinumCustomer.

枚举可能更好，但对于任何不是固定的东西，我不会使用结构（既不class也不枚举）。某些运动中的场地位置可能是一个枚举，因为它们是固定的。如果它们发生变化，那么它就足以保证代码更改。

为此，我会用一些领域概念以更 generic/fluid 的方式表示模式，但 YMMV。

命令消息——分类设计题

Command Messages - classification design question

java

domain-driven-design

cqrs

event-sourcing