代码之家 › 专栏 › 技术社区 › ioreskovic

微服务输入输出域模型

kafka-topic microservices domain-driven-design dependencies

ioreskovic · 技术社区 · 6 年前

如果我有一个服务a,它从我无法控制的外部服务获取数据,我就不得不适应外部系统提供的数据格式(域)。按照这样的做法,我的服务A将其结果以自己的格式(域)推送到主题。

现在,由A和B生成的数据的语义是相似的,但不相同。但是,管道中的下一步是服务C,它应该消耗a和B产生的东西,对它做些什么,然后吐出结果。

C是否应该只知道如何使用一个地方的数据,这意味着A&B(以及将来的其他任何一个)需要在C特定域中生成它们的输出吗?这就意味着,如果C消费者改变了它的域,A,B,和任何其他的生产者都必须改变,这是我不喜欢的。另外,如果我加上另一个消费者,例如,D,这意味着A和B,用这个类比,应该知道D也是他们的消费者,这在我看来很可怕。

我认为C应该负责它的输入,这意味着它依赖于a和B模型(以及任何其他可能产生自己数据的模型)。它还意味着,当添加一个新的源代码时,必须将C更改为也包含该数据。

实际上,我倾向于使用manysourcesonesink组件,而不是onesourcesmanysinks。

有什么可取的做法吗?

4 回复 | 直到 6 年前

VoiceOfUnreason 6 年前

有什么可取的做法吗?

也就是说,您可以将它们转换为消息格式mA、mB和mC,而不是将A、B和C相互耦合。只要(mA,mB,mC)兼容,这些服务就能够相互通信。

实现这一点的一种方法是将mA、mB和mC限制为同一模式的不同“版本”,其中模式的演化受到限制

初始版本之后不能添加新的必填字段
可选字段应具有默认值
使用者应忽略未识别的字段
HTTP status code 306 )

格雷格·杨的书 Versioning in an Event Sourced System

一个服务是否应该针对自己的主题生成输出,并使依赖服务从中消费,反之亦然,或者是否应该选择第三个选项?

基本上,这就是管道——我们如何从一个系统到另一个系统获取消息的副本?

从概念上讲,您似乎希望C使用一个逻辑 outer join 由A和B产生的消息。因此,我想最直接的问题是,当前是否有来自A的这些消息的消费者不想要来自B的消息,反之亦然。如果这是您所知道的唯一用例,那么将事情简化为单个主题可能会有好处。

choquero70 6 年前

你说的是上下文映射。BCs之间的关系。上游和下游。在两个业务连续性之间的关系中,决定哪一个是上游业务连续性和下游业务连续性不是您的选择。它们本身就是。您可以选择如何集成(使用RESTAPI、使用事件、同步、异步等)。您应该绘制一个上下文图,确定哪个战略模式适用于bc之间的每个关系,并决定如何实现它。

guillaume31 6 年前

在您选择集成模式之前,需要在战略层面上对业务子域、维护这些服务的团队、谁拥有什么、您期望模型如何发展等进行分析。

我建议看一下 DDD book 然后 Enterprise Integration Patterns 由霍普和伍尔夫具体实施。

user10367961 user10367961 6 年前

您的每个服务都应该使用对其特定业务逻辑最有意义的数据格式。

出于集成目的:

Inbound channel adapters -将数据转换为所需的格式服务。
Outbound channel adapters -将数据转换为所需的格式出口服务。

https://www.enterpriseintegrationpatterns.com/patterns/messaging/ChannelAdapter.html