Architecture DDD中主数据和参考数据的有界上下文

我对DDD的概念比较陌生，并且发现有很多例子可以解释如何为相对简单的场景定义有界上下文，但有一个领域似乎没有涉及到主数据和参考数据

我所指的参考数据类型包括货币代码、国家代码和计量单位，它们将用于确保只使用有效值

我所指的主数据类型是实体，例如客户和产品，它们不要求不同的有界上下文对实体有自己的观点。我理解，在某些情况下，开票有界上下文中的客户实体与发货有界上下文中的客户实体不同，但就本问题而言，我们可以假设开票和发货都需要完全相同的客户数据

---

我的问题是，在一个具有多个有界上下文的应用程序（如ERP系统）中，主数据和参考数据应该在一个公共有界上下文中定义，还是应该在每个有界上下文中复制这些实体，即使它们包含完全相同的数据？

在各种DDD书籍中，拥有这个域模型的共享子集称为

共享内核

。共享域模型的主要问题是，如果两个或多个软件团队（每个团队在不同的有界上下文中工作）想要更新共享内核中的任何内容，那么他们必须与其他团队商定更改的副作用。它还用来自其他有界上下文的术语和人工制品污染其他有界上下文

---

例如，如果开票团队希望向其

客户

实体添加

忠诚折扣百分比

属性，则共享此域实体的其他团队将必须接受此属性，该属性与他们自己的有界上下文无关。

Customer

实体将很快从许多单独的有界上下文中提取人工制品，并且将无法在任何单个上下文中描述客户。

可以通过REST API持久化/访问参考数据。此API负责保护和持久化数据。api将参考数据转换为对象图（在两个方向上），用于创建领域模型。每个客户机BC一个图形。一个好的身份验证策略应该会有所帮助。如果一个团队需要一些新的东西，现在它可以添加或修改它的图表，而不会给其他团队带来风险。一个好的版本控制策略应该会有所帮助。推送到API的更新应该是同步的和事务性的。如果可能的话，读取操作无法防止在可以避免的情况下对其施加压力。

请小心公开业务图，而不是单个属性。图形仍然可以合法地使用给定上下文中的引用数据，并且可以验证它（在DDD透视图中）。单一属性不允许这样做。RESTAPI还可以以某种方式负责验证它。