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

时间:2015-03-24 20:53:23

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

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

参考数据I&m; m的类型将是货币代码,国家代码和计量单位,它们将用于确保仅使用有效值。

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

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

2 个答案:

答案 0 :(得分:0)

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

例如,如果开票团队希望向其LoyaltyDiscountPercentage实体添加Customer属性,则共享此域实体的其他团队必须接受与其自己的有限无关的此属性上下文。 Customer实体很快将从许多独立的有界上下文中获取人工制品,并且无法在任何单一环境中描述客户。

答案 1 :(得分:0)

可以通过REST API持久保存/访问参考数据。此API负责保护和保留数据。 api将参考数据转换为用于水合域模型的对象图(在两个方向上)。每个客户BC的一个图。良好的身份验证策略应该有所帮助。如果团队需要新的东西,现在只需添加或修改其图表,就可以没有其他团队的风险。一个好的版本控制策略应该有所帮助。推送到API的更新应该是同步和事务性的。如果可能的话,读取操作不能防止在可以避免的情况下施加压力。