最近，我了解了ddd，它说两个相关的有界上下文之间的关系是上游和下游。
但是，在一种情况下，A可能在上游而B在下游，而在另一种情况下B可能在上游和下游吗？
但是，如果有可能，我认为这两个有限的上下文是高度耦合的。它们不是独立的业务逻辑。因此，当发生这种情况时，是否意味着我们没有将域正确地划分为有界上下文？
或者我们确实允许两个有界上下文之间进行某种程度的通信，并且如果它们相互调用的API太多，它们实际上是一个有界上下文，但是我们没有正确地划分它。
上游环境将影响下游对应方，而相反情况可能并非如此。例如，假设有两个微服务与MoneyTransferService一起作为有界上下文NotificationService。如果汇款了，通知应发送一封电子邮件给客户，其中包括一些与交易有关的信息。所以MoneyTransferService是上游NotificationService是下游
DDD描述了几种组织模式，可以帮助我们描述和/或管理不同上下文交互的方式。这里最合适的模式称为反腐败层（ACL）。为了在我的示例中遵循此模式，可以使用两个微服务进行通信，Repository layer或者更好的解决方案是发布消息并通过RabbitMQ之类的工具使用它们。通过使用RabbitMQ，这些服务仅取决于消息类型，而无需了解其他信息。
就依赖关系而言，有限上下文之间的交互并不意味着它们之间具有依赖关系，您不必将它们重新设计为有限上下文。
您的目标应该是根据您的领域知识实现最有意义的分离。重点不是规模，而是业务能力。另外，如果基于大量的依赖关系在应用程序的特定区域需要明确的内聚性，那么这也表明需要单个有界上下文。彼此需要彼此完成其业务操作的有限上下文之间的通信没有任何问题。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句