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

Question

最近学习了ddd，上面说两个相关的限界上下文是上游和下游的关系。

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

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

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

标签： domain-driven-designbounded-contexts

Answer 1

上游上下文将影响下游对应物，而相反的情况可能并非如此。例如，假设有两个微服务作为有界上下文，MoneyTransferService以及NotificationService. 如果资金被转移，通知应向客户发送一封电子邮件，其中包含一些与交易相关的信息。MoneyTransferService上游 也是 NotificationService下游

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

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

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