我对 DDD 的概念相对较新，发现有很多示例可以解释如何为相对简单的场景定义有界上下文，但似乎没有涵盖的一个领域是主数据和参考数据。
我所指的参考数据类型包括货币代码、国家代码和计量单位，它们将用于确保仅使用有效值。
我所指的主数据类型是客户和产品等实体，它们不需要不同的有界上下文拥有自己的实体视角。我知道在某些情况下，发票有界上下文中的客户实体与运输有界上下文中的客户实体不同，但出于这个问题的目的，我们可以假设发票和运输都需要完全相同的客户数据。
我的问题是在具有多个有界上下文的应用程序（例如 ERP 系统）中，主数据和参考数据是否应该在一个共同的有界上下文中定义，或者这些实体是否应该在每个有界上下文中重复，即使它们将包含完全相同的数据？
【问题讨论】：
标签： architecture domain-driven-design bounded-contexts master-data-management
在各种 DDD 书籍中，拥有该域模型的共享子集称为Shared Kernel。共享域模型的主要问题是，如果 2 个或更多软件团队，每个工作在不同的有界上下文上，想要更新共享内核中的任何内容，他们必须与其他团队就更改的副作用达成一致。它还使用来自其他有界上下文的术语和人工制品污染了其他有界上下文。
例如，如果开票团队希望将LoyaltyDiscountPercentage 属性添加到他们的Customer 实体，共享此域实体的其他团队将不得不接受与他们自己的限界上下文无关的此属性。 Customer 实体很快就会从许多单独的有界上下文中获取人工制品，并且无法在任何单一上下文中描述客户。
【讨论】：
可以通过 REST API 保存/访问参考数据。此 API 负责保护和持久化数据。该 API 将参考数据转换为对象图（双向），用于水合域模型。每个客户端 BC 一张图。一个好的身份验证策略应该会有所帮助。如果一个团队需要新的东西，它现在可以添加或修改它的图表，而不会给其他团队带来风险。一个好的版本控制策略应该会有所帮助。推送到 API 的更新应该是同步的和事务性的。如果可能，读操作不能避免强调它，如果可以避免的话。
【讨论】：