【问题标题】:How to improve my design to handle a business rule spanning multiple microservices/bounded contexts?如何改进我的设计以处理跨越多个微服务/有界上下文的业务规则?
【发布时间】:2020-12-14 11:51:38
【问题描述】:

我正在练习使用微服务建立一个系统,并通过将每个微服务设计为尽可能松耦合和自治来构建这个系统。 我正在设置的应用程序必须能够管理视频租赁系统。 为此,我有以下微服务,每个都有自己的有界上下文:

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

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

  • 在线帐户:允许您管理一个帐户(登录名和密码)以在用户希望查看其租赁列表时识别用户, 退订。

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

  • 订阅:管理用户的订阅,并根据他的付款方式对该用户的账户进行扣款。

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

  • 为了不让用户群不断增长:用户和他的所有数据在 3 个月不活动后被清除 (没有新的租金)如果:
  • 他目前没有租金
  • 他的订阅没有尚未结清的未结付款

这个规则使用了几个微服务,所以我尝试从用户微服务来管理这个: 我在那里创建了一个每天在后台运行的服务:

  • 对于最后租用日期超过 3 个月的所有用户:我与租用服务商确认 自该日期以来没有其他记录。我跟订阅微服务查了一下,没有未付费的 上课。 然后如果没有活动或未付款,我向微服务请求租金,订阅, 在线帐户将用户标记为删除(软删除) 用户及其自该日期起的数据+每个微服务特定的时间段将被物理删除。 如有必要,始终可以在每个微服务上独立取消软删除。

你觉得这个设计怎么样?对我来说,它允许在每个微服务中保持自治。

我认为另一种选择是尝试保持在用户服务级别: 最后一次出租完成的日期、最后一次进行中的出租的日期以及最后一次未偿债务的日期。 这将允许我管理我在用户微服务中的所有删除并仅发出 2 个事件:

  • 用户因不活动而被标记为删除
  • 用户在第一次事件后的一段时间后被删除

另一方面,这些必须发出事件:

  • 租赁开始时
  • 租赁结束时
  • 当有未付款时
  • 未偿债务清偿时 并且我保留了所有这些事件的历史记录以及用户微服务级别的未付账单和租金的历史记录: 追踪这些历史可能不是责任,对吧?

【问题讨论】:

    标签: architecture microservices bounded-contexts


    【解决方案1】:

    我认为你在正确的轨道上。删除非活动/无效用户可以被视为特定服务的责任,该服务充当协调器。

    一种可能的方法是将用户 ID 连同他们的最后操作日期一起存储在按日期排序的最小堆中。每次整个系统发生事件(例如出租、配置文件更新等)时,此微服务都会更新本地数据并刷新堆状态。 此时,您的“清除”任务应该只是从顶部遍历堆,提取节点(-> 要删除的用户 ID)直到它没有达到有效日期。

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

    【讨论】:

      猜你喜欢
      • 2021-01-29
      • 1970-01-01
      • 2023-04-10
      • 1970-01-01
      • 1970-01-01
      • 2015-05-02
      • 2020-02-27
      • 2012-12-26
      • 1970-01-01
      相关资源
      最近更新 更多