domain-driven-design - ddd中上游上下文和下游上下文之间的关系

Question

最近学习ddd，里面说两个相关的bounded context之间的关系是upstream和downstream。

但是有没有可能在一种情况下A是上游B是下游，而在另一种情况下B是上游又是下游？

但是如果可以的话，我觉得这两个bounded context是高度耦合的。它们不是独立的业务逻辑。那么当发生这种情况时，是否意味着我们没有将域正确划分为有界上下文？

或者我们确实允许两个限界上下文之间在某种程度上进行通信，如果它们相互调用的 API 如此之多，那么它们实际上是一个限界上下文，但我们没有正确划分它。

Answer 1

上游环境会影响下游对应物，反之则不然。例如，假设有两个微服务作为限界上下文，MoneyTransferService 和 NotificationService。如果转账，通知应向客户发送一封电子邮件，其中包含一些与交易相关的信息。所以MoneyTransferService 是上游NotificationService 是下游

DDD 描述了几种组织模式，可帮助我们描述和/或管理不同上下文交互的方式。这里最合适的模式称为反腐败层 (ACL)。为了在我的示例中遵循这种模式，与两个微服务进行通信，可以使用 Repository layer 或者更好的解决方案是发布消息并通过 RabbitMQ 等工具使用它们。通过使用 RabbitMQ，这些服务仅依赖于消息类型，无需了解任何其他信息。

就依赖关系而言，限界上下文之间的交互并不意味着它们之间存在依赖关系，您不一定需要将它们重新设计为限界上下文。

您的目标应该是在您的领域知识的指导下实现最有意义的分离。重点不在于规模，而在于业务能力。此外，如果基于大量依赖项的应用程序的某个区域需要明确的内聚性，则也表明需要单个限界上下文。限界上下文之间的通信没有任何问题，它们需要彼此来完成其业务操作。