我已经读过，将应用程序拆分到不同的有界上下文中的原因是因为无处不在的语言以及拆分大实体。例如，我可以有一个 Product 实体，其中包含 Support 和 Sales 的逻辑，我可以在不同的有界上下文中将模型拆分为两个 Product 模型 - Support 和 Sales 有界上下文，但我也可以只创建两个不同的实体 SupportProduct 和 SalesProduct 并实现同样的结果？那么为什么我还需要不同的限界上下文呢？
【问题讨论】：
标签： domain-driven-design bounded-contexts
有界上下文实际上与应用程序或代码没有任何关系，它们用于分解问题，并且是一种记录销售领域专家和支持领域专家在谈论产品时的含义不同这一事实的手段。 .
所以SupportProduct 和SalesProduct 是“产品”存在于两个不同的有界上下文中这一事实的有效编码；如果你的目标是在不支持模块/包/命名空间的语言中实现更单一的实现，你可以选择这种编码（在一种确实支持这种支持的语言中，你可能有类似 sales.Product 和 support.Product 的东西） .
有界上下文并不意味着代码结构或部署到不同（可能是微）服务中的任何内容，尽管这种分解确实暗示了一些用于构建代码/部署的自然接缝。
【讨论】：
SupportProduct 和 SalesProduct 是开始的有效选项。将Product 和Sales 分开在 2 个不同的可部署单元中，如果 2 个不同的团队负责每个限界上下文，将会派上用场。 Product 和 Sales 可以有不同的生命周期。