oop - 判别器字段和数据建模

Question

我有以下情况。

一个预订，这个预订被取消，它可以重新创建它可以被确认它可以被拒绝。

取消的原因可能不同。假设预订已过期，或者可能未在特定时限或其他原因内处理。

为了确认预订，应执行多个子交易。这意味着确认本身内部有一个流程。我的团队提出的解决方案是某种具有许多不同状态的工作台。这很好。我觉得有必要通过声明一个字段 ReservationStatus 来唯一标识预订的状态，该字段描述了表中已经定义的状态的某些变化。在这种情况下，预订状态将为 NEW、CONFIRMED、CANCELED、REJECTED。每个状态将描述工作表中状态的某些变化。

我的团队确信这会增加额外的复杂性。我认为这是相反的，它简化了流程。它还声明了一个自然鉴别器和多态性。我们应该使用队列和异步进程。

实际上，我怎么能证明我们应该有这样的专栏，因为我已经提到的论点还不够，而且在内心深处我知道我是对的:)？

标签： oopdesign-patternsmodeldomain-driven-design

Answer 1

想要这是一个评论，但它出现的时间太长了，所以就这样吧。

@AlexandarPetrov 我会添加以下问题：

• 是否所有状态都具体代表了保留可能拥有的每个状态？
• 所有状态迁移路径是否都有明确的规则？例如过期 -> 确认等等。
• 您需要对状态变化进行建模吗？它是有限状态机吗？

我个人会公开状态字段，但前提是它本身足够具体以定义状态。例如，我见过有 2 层状态的情况——状态和子状态。在这种情况下，边界丢失，状态变成复杂的 VO 而不是简单的字段，状态转换规则可能会变得模糊。

另外： 对我来说，事件溯源和 CQRS 似乎非常适合所有这些预订。特别是考虑到您提到的复杂流程。然后转换将是正在应用的事件和状态 - 一种暴露状态的简单方法。由于事件流包含所有历史数据，因此也无需单独跟踪状态更改。

最后：

实际上，我怎么能证明我们应该有这样的专栏，因为我已经提到的论点还不够，而且在内心深处我知道我是对的:)？

好吧，最后你总是可以放下你的脚并承担责任。如果事实证明这是一个错误的决定 - 承担责任并承认错误。