software-design - 确定客户是否可以修改或取消订单的最佳实践

Question

我目前正忙于对一个小型电子商务应用程序进行大规模重构，客户可以在其中下订单（用于三明治等）。客户必须在特定时间之前下订单，以便公司可以保证订单准时准备好。这是通过配置某些截止日期来完成的。还有一个截止日期，告诉我们客户可以修改或取消现有订单的时间。实际截止日期取决于所选的交货日期，因此每个订单都不同。

此时，我们只需在需要时即时计算截止日期。截止日期结果只是一个DateTime. 计算逻辑本身已经在一个地方（IDeadlineValidator），因为它需要一个数据库调用来获取一些额外的数据，我们只是不想在整个应用程序中重复它（DRY 原则）。但这IDeadlineValidator会在整个应用程序中调用，因为截止日期也用于操作 UI（显示修改按钮和那些东西）。但它变得有点混乱，我相信有更好的方法来做到这一点。

我现在的问题是：确定订单是否可以修改的最佳实践是什么？我也在寻找最好的表现。

我已经想出的几个解决方案是：

• 下订单后立即计算截止日期并将其存储在数据库中，例如CanModifyUntil。然后应用程序必须检查是否CanModifyUntil < CurrentDate.
• CanModify使用默认值存储一个布尔值，true并在后台每隔半小时左右（重新）计算一次，直到该值变为false.
• 第三种选择是前两种的混合。下订单时，设置CanModify为true，计算截止日期，然后在实际截止日期安排后台作业，只需切换CanModify到false。
• 或者就让它保持原样...

你有什么想法？

标签： software-design

Answer 1

如果可以预先计算截止日期并且它是决定是否可以更改订单的唯一因素，我喜欢您提出的第一个选项，即计算一次然后存储结果。如果您想抽象它以防它发生变化，您仍然可以在服务方法中进行检查。

此选项可以帮助您稍微优化前端代码（我假设这是带有 Web 客户端的客户端/服务器） - 因为您可以检查以启用/禁用前端的按钮。当然，如果有人直接调用您的 API，为了安全起见，您仍然需要在服务器端检查它，但这意味着您不会为了渲染前端而进行额外的调用。

其他两个选项听起来过于复杂——如果计时器由于某种原因未能触发怎么办？逻辑现在解耦了，理论上订单可能会处于无效状态，因为您的状态操作逻辑位于其他位置。