由不同的微服务定义和使用的通用模型

时间:2018-12-16 16:46:53

标签: domain-driven-design microservices

在一个场景中,我们正在监视所谓的终结点计算机。我们通过某种机制来接收卡夫卡中一台计算机中发生的事件的数据。 两种不同的微服务正在侦听该主题以处理数据。两种服务都有不同的用途

  1. 警报:用于根据主题中的数据生成警报。
  2. 资产:向您的客户显示该主题中的机器事件数据。

我看到的问题是,我们为以下情况定义了通用模型作为库:

  • 在要发送到kafka的计算机上序列化数据以使用服务。
  • 要反序列化上述两个服务(警报和资产)消耗的数据

我认为这是在微服务环境中定义模型的错误方法,因为这会在子域之间引入耦合,这些子域彼此之间不直接相关,并且代表不同的有界上下文。在上述情况下

  • 警报(有界上下文):根据数据生成警报。(业务能力或子域)
  • 资产(有界上下文):向客户端(另一个子域)显示机器事件数据

作为库的通用模型还满足以下要求:

  • 有界上下文对它们必须具有自治性的基本要求,通用模型的更改将影响这两种服务。
  • 微服务应该是可独立部署的,即使更改对任何一种服务都没有用,对模型的更改也将强制将两种服务分别部署。

我认为适合这种情况的解决方案是为这两个服务使用单独的模型而不是通用模型来表示主题中传入数据,或者通过请求另一个服务并创建一个这两个服务之间的关联。

需要了解哪种是微服务的正确方法。

1 个答案:

答案 0 :(得分:1)

也许您目前所处的情况可能有些独特之处,我现在看不到,这可能意味着您需要拥有一个公共库但是据我所知,拥有公共库的现有实现没有什么问题。

在某些情况下,您甚至可能拥有一个Shared Kernel

这不是将不同的有界上下文耦合在一起,但是您 依赖一些功能,这些功能在更改时可能会导致您的端点需要重新设计和重新部署。一个以上有界上下文依赖于该功能这一事实是无关紧要的。

我可能会以相同的方式使用一些Nuget软件包,该软件包已升级并具有中断的主要版本,导致升级到该版本需要重新部署我的端点。尽管在这种情况下,它可能是实际端点,并且与有界上下文域模型没有直接关系。