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