我正在阅读实现领域驱动设计并努力解决上下文映射的概念。
这本书在描述不同上下文如何通信时使用的语言，“RESTful”“开放主机服务”，“另一个团队”让我怀疑我是否有多个上下文。
这只是我一个开始，所以没有其他团队，但我仍然想将我的项目分割成上下文，但显然他们需要沟通。
上下文将部署在一个进程中，因此它们可以简单地调用彼此的方法，因此每个上下文之间不需要Web服务，但是本书的上下文映射部分似乎没有处理这个问题。
那么这些上下文是如何通信的，或者是我所描述的，因此清楚地描述了一个上下文，因为它是一个团队并且没有 Web 服务。
无论实际的传输实现（进程内或 HTTP）如何，上下文映射都适用。即使您是一个团队，您当然也可以使用多个有界上下文。这本书涵盖了更复杂的集成场景，以解决协调多个团队的困难，但无论如何这些原则都适用。例如，一旦您在单个应用程序中实现了多个上下文，您可能希望仅出于封装目的而将它们彼此隔离。如果是这样，那么创建一个 HTTP 服务来公开每个上下文的已发布功能是一种选择。即使只有少数开发人员在代码库上工作，这也是可取的。您还应该考虑的是您是否实际上有多个有界上下文。例如，您可能有多个模块，
有界上下文是关于模型的。单一型号？单一有界上下文。多种型号？多个有界上下文。
在定义这些上下文的界限时，团队组织开始发挥作用。一个团队可以在多种环境中工作，并且（非常小心）多个团队可以在相同的环境中工作。关键是要明确这一点。
您如何集成限界上下文（Web 服务、进程内等）实际上并不重要。重要的是上下文之间的关系类型 - 这将进入您的上下文映射。