鑒別器領域和數據建模

Question

我有以下情況。

保留，此保留被取消，可以重新創建，可以確認，可以拒絕。

取消的原因可能不同。 可以說預訂已過期，或者在一定時限或其他原因下可能尚未處理。

為了確認預訂，應執行多個子交易。 這意味着確認本身中存在一個流程。 我的團隊提供的解決方案是一種具有許多不同狀態的工作表。 沒關系 我感到需要通過聲明一個字段ReservationStatus來唯一標識保留狀態，該字段描述了表中已定義的某些狀態變化。 在這種情況下，預留狀態將為NEW，CONFIRMED，CANCELED，REJECTED。 每個狀態將在工作表中描述狀態的某些變化。

我的團隊確信這會增加額外的復雜性。 我認為這與簡化流程相反。 它還聲明了自然的區分和多態性。 我們應該使用隊列和異步進程。

實際上，我如何才能推斷出應該有這樣的專欄，以取代我已經提到的論點還不夠，並且深入我的內心，我知道我是正確的:)？

Answer 1

希望對此發表評論，但發表時間太長，因此無法進行。

@AlexandarPetrov我將添加以下問題：

• 所有狀態是否具體代表保留可能擁有的每個國家？
• 所有狀態遷移路徑都有明確的規則嗎？ 例如，過期->確認等等。
• 您需要對狀態變化進行建模嗎？ 它是有限狀態機嗎？

我親自公開狀態字段，但前提是狀態字段本身足夠具體以定義狀態。 例如，我看到了兩層狀態-狀態和子狀態的情況。 在這樣的情況下，邊界將丟失，狀態變為復雜的VO，而不是簡單的字段，狀態轉換規則可能變得模糊。

另外：對我來說，事件采購和CQRS似乎很適合所有這些預訂。 特別要記住您提到的復雜流程。 然后過渡將是應用的事件和狀態-公開狀態的一種簡單方法。 由於事件流保存了所有歷史數據，因此也無需單獨跟蹤狀態更改。

最后：

實際上，我如何才能推斷出應該有這樣的專欄，以取代我已經提到的論點還不夠，並且深入我的內心，我知道我是正確的:)？

最后，您總是可以放下腳步並承擔責任。 如果事實證明是錯誤的及時決定，則要承擔責任並承認錯誤。