Domain driven design 不同微服务定义和使用的通用模型

我们有一个场景，我们在监视机器，即所谓的端点。我们通过某种机制接收卡夫卡机器中发生的事件的数据。 两个不同的微服务正在收听主题以处理数据。这两项服务有不同的目的

警报：用于根据主题中的数据生成警报

资产：向客户显示主题中的机器事件数据

我看到的问题是，我们为以下情况定义了一个通用模型作为库：

• 序列化要发送到kafka的机器上的数据，以便使用服务
• 对上述两个服务（警报和资产）使用的数据进行反序列化

我觉得这是在微服务环境中定义模型的一种错误方法，因为它引入了子域之间的耦合，这些子域彼此之间没有直接关系，并且表示不同的有界上下文。在上述情况下

• 警报（受限上下文）：基于数据生成警报。（业务能力或子域）
• 资产（有界上下文）：向客户端显示机器事件数据（另一个子域）

此外，作为库的通用模型也违反了以下要求：

---

• 有界上下文的基本要求是它们必须是自治的，公共模型中的更改将影响任何一个服务
• 微服务应该是可独立部署的，模型中的更改将强制两个服务分开部署，即使更改对任何一个服务都没有任何用处

我认为适合此场景的解决方案是，为两个服务提供单独的模型，而不是公共模型，作为主题中传入数据的表示，或者通过请求另一个服务来使用一个服务中的数据，并在两个服务之间创建关联

---

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

也许有一点可能是您的情况所独有的，但我现在没有看到这一点，这可能意味着您不需要有一个公共库，但从我可以看出，您现有的具有公共库的实现没有任何问题

在某些情况下，您甚至可能有一个

共享内核

，正是这样

这并不是将不同的有界上下文耦合在一起，而是依赖于一些功能，当这些功能发生变化时，可能会导致端点需要一些返工和重新部署。多个有界上下文依赖于该功能这一事实是无关紧要的

---

以同样的方式，我可能正在使用一些

Nuget

软件包，该软件包使用一个中断的主版本进行升级，导致升级到该版本时需要重新部署我的端点。虽然在这种情况下，它可能是实际的端点，与有界上下文域模型没有直接关系。

“有界上下文的基本要求，即它们必须是自治的”-不完全正确：DDD书中描述的上下文映射实践提出了不同的策略来集成BC。你可能也会觉得有趣。你是对的，但它在有限的上下文之间的集成和协作，不通过共享域模型在有界上下文之间创建不必要的依赖关系，域模型在不同的有界上下文中会发生不同的变化。BC1与BC2之间没有关系，以及它是如何变化的。那么，我并不真正理解你问题的重点。你只是在抱怨你不能拥有你的蛋糕（一个共享的模型）并吃掉它（每个BC都可以独立进化）？从一开始我就觉得很明显……上下文映射有很多选项可供选择，包括“单独的方式”（即不共享/集成）。无论如何，必须做出权衡，你只需要做出决定。就我的2c：“自主业务组件”可能更多地与有界上下文/微服务的内聚和部署有关，而不是依赖关系。共享内核通常用于交叉关注点，如身份验证等，如果在所有服务中都发生更改，则会使用共享内核。但共享模型并不是一种理想的方法，因为一个服务中的更改将导致另一个服务的更改，并在服务之间创建不必要的依赖关系。实际上，每个服务可以有不同的模型，因为它们在任何方面都不相互依赖。当依赖于模型的服务数量很小时，这很好，但逐渐地，它会带来麻烦，并不是设计微服务的好方法，我相信…您共享的示例更多的是一种行为功能，在服务之间作为库共享，这绝对有意义，但是，跨微服务共享实体或价值对象，或者更确切地说是域模型，似乎并不是设计微服务的好方法。你的想法是什么…我想这将取决于“沟通方向”。。。如何使用共享位（基本上是@guillaume31在他的评论中提到的）。像

Identity&accesscontrol

这样的东西可以很容易地成为一个通用子域，您可以很容易地在有边界的上下文中共享它。我想你需要选择你的毒药：）---但说实话，除非你处于发展的早期阶段，变化频繁，否则不应该像你所说的那样造成破坏。现在还不是早期阶段，几乎在相当长的一段时间内，这些服务都是构建的，IMO即使在其早期或后期，也应该绝对避免这种通过不相关BC之间的共享模型实现的聚合，这样我们就不会逐渐将环境变成一个分布式的整体。无论服务的使用期限如何，该模型都会不断发展。