鉴别器领域和数据建模 [英] Discriminator field and data modeling

问题描述

我有以下情况.

预订，此预订被取消，可以重新创建，可以确认可以拒绝.

A reservation, this reservation be canceled, it can be newly created it can be Confirmed it can be rejected.

可能有不同的取消原因.可以说预订已过期，或者在一定时限或其他原因下可能未进行处理.

There might be different reasons for cancelation. Lets say the reservation has expired, or it may have not been processed within certain timelimit or some other reason.

为了确认预订，应执行多个子事务.这意味着确认本身中存在一个流程.我的团队提供的解决方案是某种具有许多不同状态的工作表.没关系我感到需要通过声明一个字段ReservationStatus来唯一标识保留状态，该字段描述了表中已定义的某些状态变化.在这种情况下，预留状态将为NEW，CONFIRMED，CANCELED，REJECTED.每个状态将在工作表中描述状态的某些变化.

In order for a reservation to be confirmed a multiple sub - transactions should be performed. This mean that there is a flow within the Confirmation itself. The solution my team came with is some sort of work table holding many different statuses. Which is fine. I felt the need to uniquely identify the state of a reservation by declaring a field ReservationStatus that depicts certain variation of statuses that are already defined in the table. In this case the Reservation status would be NEW,CONFIRMED,CANCELED,REJECTED. Each state will depict certain variation of statuses in the work table.

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

My team was convinced that this is adding additional complexity. I think this is the opposite it simplifyes the flow. It also declares a natural discriminator and polymorphism. We are supposed to use Queues and asynchroneus processes.

实际上我该如何推断我们应该有这样的专栏，它取代了我已经提到的论点还不够，并且深入我的内心，我知道我是对的:)?

How can I actualy jsutify that we should have such column it apears the arguments I already mentioned were not enough and deep down inside I know I am right :)?

推荐答案

希望将此作为评论，但发表时间太长了，所以就可以了.

Wanted this to be a comment but it came out too long so here it goes.

@AlexandarPetrov我要添加以下问题:

@AlexandarPetrov I would add the following questions:

• 所有状态都具体代表预订可能拥有的每个州吗?
• 所有状态迁移路径是否都有明确的规则?例如已过期->已确认，依此类推.
• 您需要对状态变化进行建模吗?这是一个有限状态机吗?

我个人会公开状态字段，但前提是它本身足够具体以定义状态.例如我已经看到了两层状态-状态和子状态的情况.在这种情况下，边界会丢失，状态变为复杂的VO，而不是简单的字段，状态转换规则可能会变得模糊.

I'd personally expose the status field but only if it is concrete enough by itself to define state. For e.g. I've seen cases where there are 2 layers of statuses - status and sub-status. In a case like that boundaries are lost and state becomes a complex VO rather than a simple field and state transition rules could become blurry.

此外: 对我来说，事件搜寻和CQRS似乎很适合所有这些预定.特别要记住您提到的复杂流程.然后过渡将是应用的事件和状态-公开状态的一种简单方法.由于事件流可保存所有历史数据，因此也无需单独跟踪状态更改.

Additionally: For me it seems like Event Sourcing and CQRS could be a good fit for all those Reservations. Especially having in mind the complex flows you mention. Then transitions will be events being applied and the statuses - a simple way to expose state. Tracking status changes separately will also be needless as the Event Stream holds all historical data.

最后:

实际上我该如何推断我们应该有这样的专栏，它取代了我已经提到的论点还不够，并且深入我的内心，我知道我是对的:)?

How can I actualy jsutify that we should have such column it apears the arguments I already mentioned were not enough and deep down inside I know I am right :)?

最后，您始终可以放下脚步并承担责任.而且，如果事实证明是错误的及时决定，则要承担责任并承认错误.

Well at the end you can always put your foot down and take responsibility. And if it turns out to be a wrong decision in time - bare the responsibility and admit the mistake.

这篇关于鉴别器领域和数据建模的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！