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