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

Question

我对 DDD 的概念相对较新，并且发现有很多示例解释了如何为相对简单的场景定义有界上下文，但似乎没有涵盖的一个领域是主数据和参考数据。

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

我指的主数据类型是诸如客户和产品之类的实体，其中不需要不同的有界上下文拥有自己的实体视角。我知道在某些情况下，发票有界上下文中的客户实体与运输有界上下文中的客户实体不同，但出于此问题的目的，我们可以假设发票和运输都需要完全相同的客户数据。

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

Answer 1

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

Shared Kernel

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

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

LoyaltyDiscountPercentage

实体添加

Customer

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

Customer

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

Answer 2

可以通过 REST API 保存/访问参考数据。该 API 负责保护和保存数据。该 API 将参考数据转换为对象图（双向），用于水合域模型。每个客户 BC 一张图表。良好的身份验证策略应该会有所帮助。如果一个团队需要新的东西，现在可以添加或修改其图表，而不会给其他团队带来风险。良好的版本控制策略应该会有所帮助。推送到 API 的更新应该是同步的和事务性的。如果可能的话，读取操作不能避免对其施加压力（如果可以避免的话）。

Answer 3

主数据管理 (MDM) 是领域驱动设计 (DDD) 的对立面，属于一个强集中化和治理被认为是解决一切问题的正确答案的时代。主客户或产品实体首先就会违背定义有界上下文的目的。

正如我们在埃里克·埃文斯 (Eric Evans) 的书中所读到的：

[共享内核]的目标是减少重复（但不是消除重复，如果只有一个有界上下文，就会出现这种情况）。

您的假设，

we can assume that both invoicing and shipping need exactly the same customer data

，它是一个陷阱，导致我所知道的所有 MDM 项目都惨败。一开始这可能是正确的，但当应用程序或业务环境或两者都向前发展并导致不同的环境相互分歧时，很快就会证明自己是一个谬论。

总而言之，集中式域实体是一个非常糟糕的主意，就像在微服务之间共享集中式库一样。