architecture - DDD 中主数据和引用数据的有界上下文

标签 architecture domain-driven-design bounded-contexts master-data-management

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

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

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

我的问题是在具有多个有界上下文(例如 ERP 系统)的应用程序中,主数据和引用数据是否应该在一个共同的有界上下文中定义,或者这些实体是否应该在每个有界上下文中重复,即使它们包含完全相同的数据?

最佳答案

在各种 DDD 书籍中,拥有该领域模型的共享子集称为 Shared Kernel。 .共享域模型的主要问题是,如果 2 个或更多软件团队,每个工作在不同的有界上下文上,想要更新共享内核中的任何内容,他们必须与其他团队就更改的副作用达成一致。它还使用来自其他有界上下文的术语和人工制品污染了其他有界上下文。

例如,如果发票团队希望添加 LoyaltyDiscountPercentage属性(property)到他们的Customer实体,共享此域实体的其他团队将不得不接受与他们自己的有界上下文无关的这个属性。 Customer实体很快就会从许多单独的有界上下文中获取人工制品,并且将无法在任何单一上下文中描述客户。

关于architecture - DDD 中主数据和引用数据的有界上下文,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/29242669/

相关文章:

domain-driven-design - 领域驱动设计中跨界上下文的实体

wcf - Node.js 在 Microsoft/Azure/WCF/MVC 项目中适合什么位置?

domain-driven-design - 值对象可以有行为吗?

database-design - 重写系统...保留旧模式?

asp.net - 同时使用 Application Service 和 Manager 的目的是什么?

domain-driven-design - 真实世界的 DDD : Structuring the Domain Layer

domain-driven-design - DDD : Syncing bounded contexts causing different domain behavior/logic

domain-driven-design - DDD 跨有界上下文引用子实体

java - 扩展 logback 并允许客户端使用干净的 slf4j

python - 在 python 和 haskell 进程之间进行通信的 ipc 库是什么?