有限上下文在微服务世界中意味着什么？

Question

我一直在学习实施微服务，但我无法理解术语“有界背景”？

我可以理解它是由域驱动设计产生的概念。但我无法理解它的技术实现。

我看了下面的链接：

1. microservices and bounded contexts
2. https://martinfowler.com/bliki/BoundedContext.html
3. https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/microservice-ddd-cqrs-patterns/microservice-domain-model

Answer 1

这是一个最大的区域/区域/地方，其中一个术语具有一致的含义（对于业务专家和开发人员来说，这意味着同样的事情）。我故意避免使用＆＃34; context＆＃34;这个词。理想情况下，有界上下文恰好是来自现实世界的域。

当谈到微服务时，微服务不应该大于有界上下文。

更新

如果系统设计正确，则Bounded context 应为独立域名;实际上，当事情没有正确完成时，Bounded context比域大。在大型企业中，一些开发人员创建了试图捕获与某个术语相关的所有行为的对象（模型）。例如，商店中的Product。这个词非常广泛。来自在线商店的Product和来自库存系统的Product不是同一件事，尽管它们看起来可能是这样的。在这种情况下，网上商店应该是有限的上下文，而库存应该是不同的。

<强>实施

每个＆＃34;产品＆＃34;例如，每个有界上下文中应该有一个不同的类。有界上下文可以实现（更好的表达式可以被视为＆＃34;可以被视为＆＃34;）a namespace或package在整体中，或者作为分布式系统中的微服务。

Answer 2

有界上下文是一个独立的域。让我们把它想象成一个公司的不同部门。像关注点分离的东西。所有利益相关者（业务分析师，测试人员，开发人员，业务人员）在有界上下文中使用的术语定义相同的独立上下文。然后，您可以拥有与每个Bounded Context相对应的单独微服务。例如：如果您在保险域中，那么您可以拥有有限的上下文，如客户，报价，政策等，并且可以为每个人提供微服务。