【发布时间】:2014-10-13 23:15:50
【问题描述】:
假设我有一个对象,该对象在很大程度上具有两个不同应用程序的必要属性等,因为两个应用程序都需要使用它们。 10% 的属性可能不会在一个应用程序中使用。共享该对象(并将聚合/有界上下文作为共享内核?)还是复制存储的属性和数据更好?一个应用程序用于最终用户/活动,另一个应用程序用于管理用户/活动。
【问题讨论】:
假设我有一个对象,该对象在很大程度上具有两个不同应用程序的必要属性等,因为两个应用程序都需要使用它们。 10% 的属性可能不会在一个应用程序中使用。共享该对象(并将聚合/有界上下文作为共享内核?)还是复制存储的属性和数据更好?一个应用程序用于最终用户/活动,另一个应用程序用于管理用户/活动。
【问题讨论】:
实体通常不在 BC 之间共享。你可能有另一个 BC 在玩。您应该有一个 BC,它是实体的记录系统。所有其他 BC 应该在它的下游,并且只包含数据的身份和相关位。通常,人们会采用事件驱动架构来通知相关系统有关实体状态的任何相关更改。
也可能是您尝试拆分单个 BC。或许专注于 BC 方面,而不是技术/应用方面。
希望有帮助:)
【讨论】:
我们最近开发了一个应用程序,该应用程序涉及使用大量通用实体的多个模块。当我们开发它们时,我们将这些通用实体移动到一个名为 common-domain 的项目中,然后让所有依赖模块都使用它。结果是一场灾难。
虽然我们最初发现几个属性是通用的,但我们发现我们为某些模块设计它们的方式与它们用于其他模块的方式存在冲突。更改公共域中的实体以适应一个模块的需求有时会破坏它们在其他模块中的工作方式。我们没有使用测试驱动的方法,这使得查找产生的错误变得乏味。
从这个错误中吸取教训,我们应该识别和识别有界上下文,并根据有界上下文识别实体及其相关属性。 “通用”实体应该已根据有界上下文以及该上下文所需的任何属性进行定义。有些属性肯定很常见,但由于它们是单独的有界上下文,因此必须在每个有界上下文的每个实体中声明它们。
我将进一步提及可以共享项目的位置。有界上下文中的每个实体都有自己的存储库。 “通用”实体可能共享相同的底层数据库表。检索相关列以返回适当的实体实例是每个 BC 的实体存储库的责任。
【讨论】: