【问题标题】:Polymorphism on DDD aggregatesDDD 聚合上的多态性
【发布时间】:2022-01-19 08:32:06
【问题描述】:

我正在设计我的域模型,但无法理解如何搜索具有相同 ID 的相似聚合。

假设我们有两个聚合 ActiveEmployee 和 InactiveEmployee。他们在结构上有很多差异,但也有一些共同点,因为他们都是员工,而且他们都有一个employeeId。
他们每个人都有一个带有 findById 的单独存储库,在某些情况下,我需要单独检索它们,但在某些情况下,我需要搜索员工,然后查看我得到的员工是活跃的还是非活跃的。

我首先想到让一些抽象类 Employee 有自己的存储库来进行搜索,但从我读过的内容来看,聚合不应该使用这种类型的多态性。 通过拥有两个独立的存储库,我需要在需要普通员工时检查这两个存储库,并处理我在其中一个或两个中都找不到任何存储库的情况。

在这种情况下可以使用一些最佳实践吗?

编辑:
我意识到上述情况可能无法完全表达我的问题,所以让我们试试这个:

我有两种类型的包,ProvidedPackage 不能更改,UserPackage 是由用户创建和更改的。
两者都包含模块,用户从几个不同的 ProvidedPackage 和其他 UserPackage 中选择需要哪些模块来创建新的组合包。每个模块的源包也存储在新的 UserPackage 中以供跟踪。
ProvidedPackage 包含一些关于如何使用 UserPackage 没有的特定实例模块的规则。并且 UserPackage 有一个 ProvidedPackage 没有的审批字段。 (它们之间还有其他区别)。
创建新包时,用户会从两种包类型中添加模块,而不关心它是 ProvidedPackage 还是 UserPackage。

我解决这个问题的想法是有两个单独的聚合,因为不变量有很多差异。 “PackageID”用作两种类型的标识。感觉就像父类“Package”对于我需要使用 PackageID 列表检索包的情况很有用。否则我每次都需要检查两个存储库。如果将来添加包类型,则需要添加更多检查。

【问题讨论】:

    标签: polymorphism aggregate domain-driven-design


    【解决方案1】:

    对于活跃和不活跃员工的具体情况,我真的不认为他们应该被视为不同的集合:毕竟每个员工都会在某个时候变得不活跃。通过将它们建模为单独的聚合,严格来说,您放弃了确保给定 ID 不会同时处于活动状态和非活动状态的能力。

    对于活跃和不活跃的员工有非常不同的状态模型表明这些聚合大多存在于不同的有界上下文中。您将有一个 Employment 有界上下文,它负责分配 ID 并跟踪员工是活跃还是不活跃(这可以通过 employeeStarted 和可选的 employeeFinished 字段来完成),也许还有其他常见的模型的各个方面。在只与活跃员工打交道的情况下(例如 Payroll),您有一个终止雇佣的命令(这可能反过来从该有界上下文的存储库中删除)。

    【讨论】:

    • 感谢您的回复。您的回答为我澄清了一些事情,但并没有完全触及我问题的核心。我用与我的问题更密切相关的更具体的问题编辑了我的问题。
    • 我的回答还是基本一样。你有一个包有界的上下文来管理诸如 ID 的唯一性和对所有类型的包都有意义的操作之类的事情。更具体的操作在其他有界上下文中。
    • 好吧,我觉得有道理!因此,为了确认我的理解,“创建/编辑”有界上下文仅具有“包”聚合,其中包含创建/编辑所需的字段和函数。然后在另一个有界上下文中说“批准”,将为该上下文中所需的部分定义一个 UserPackage 聚合。然后,UserPackage 将使用与创建/编辑上下文中相应“包”相同的 PackageID 来使用其存储库获取特定包?
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2014-08-11
    • 1970-01-01
    • 1970-01-01
    • 2017-05-25
    • 2016-03-21
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多