如何改进我的设计，以处理跨越多个微服务/有界上下文的业务规则？

Question

我正在实践建立一个使用微服务的系统，并通过设计每个微服务尽可能少耦合和自治来构建这个系统。我正在设置的应用程序必须使管理视频租赁系统成为可能。为此，我有以下微服务，每个服务都有自己有限的上下文：

• 视频目录:用于管理可以出租的视频列表的服务。

• 用户:管理用户数据(他们的地址，他们的付款偏好)：我还存储上次租赁的日期。

unsubscribe.

• 在线帐户:允许您管理一个帐户(登录和密码)，当用户希望查看其租金列表时，可以将其标识为

• 租房:允许您管理用户的租金列表。

• Subscription:管理一个用户的订阅，并按照他的付款方式在这个帐户上进行借方。

我为自己制定的业务规则之一是：

• 为了没有一个不断增长的用户群:一个用户和他所有的数据在3个月的不活动之后被清除(没有新的租金)如果：
• ，他没有当前的租金
• ，他的订阅没有未付的款项，但还没有解决

的问题。

这个规则使用了几个微服务，所以我尝试通过用户微服务来管理它:我创建了一个每天在后台运行的服务：

• 适用于上一次租用日期超过3个月的所有用户:我向租赁服务确认，自该日期以来没有其他记录。我向订阅的微型服务确认没有免费的课程.然后，如果没有活动或等待付款，我要求微型服务的租金，订阅，网上帐户标记用户删除(软删除)的用户和他的数据，从这个日期+一个特定的时间，每个微型服务将被实际删除。如果有必要，随时可以在每个微服务上独立地取消软删除。

你觉得这个设计怎么样？对我来说，它允许在每个微型服务中保持自主权。

我认为另一种选择是尽量保持用户服务水平:最后一次完成租赁的日期、最后一次正在进行的租金的日期以及最后一次未付债务的日期。这将使我能够管理我在用户微服务中的所有删除，并且只发布两个事件：

由于inactivity

• User而标记为删除的
• 用户在第一次事件

之后的一段时间后被删除

另一方面，它们必须发出事件：

• 在租赁
• 的开头，在租赁
• 的末尾，当未偿债务清偿时有未支付的
• ，并且我保存了所有这些事件的历史记录--在用户微观服务级别上的未付账单和租金的历史:跟踪这些历史可能不是责任，对吗？

f 247

Answer 1

我觉得你走在正确的轨道上。删除不活动/无效的用户可被视为特定服务的责任，该服务充当协调器。

一种可能的方法也可以是将用户id和他们的最后一个操作日期一起存储在一个按日期排序的最小堆中。每次在整个系统上都有一个事件(如。此微服务将更新本地数据并刷新堆状态。此时，您的“清除”任务应该从顶部遍历堆，提取节点(要删除的->用户ids )，直到到达有效日期为止。

在本例中，我只使用日期，但我想您也可以扩展到其他自定义规则。