design-patterns - 管理实体的历史对象

Question

我们正在将现有系统转换为 DDD，并且正在努力解决一些概念。

我们有一个名为 Animal 的聚合根，它具有诸如 Status 之类的属性和 Source .目前数据库有两个表，名为StatusHistory和 SourceHistory ，当状态改变时，它存储关于动物的信息。这些表有时会删除记录，并且在获取 Animal 时很少需要检索。来自 AnimalRepository .

所以最大的问题是它们属于哪里？以下是我们的一些想法:

将它们作为不同的实体对象作为动物集合的一部分。并有相应的方法来更新它们，例如:Animal.UpdateStatus(newStatus) ，这将添加到带有 new StatusHistory(this) 的集合中目的。但是如上所述，在为存储库获取现有动物时很少需要这些，因此我们不希望存储库加载它们。我们目前没有使用 ORM，而是使用存储库内的表数据网关手动映射。

使每个历史实体成为聚合根。我们不喜欢这个，因为感觉我们并没有真正对域进行建模，只是朝着 Active Record Pattern 漂流。 .为动物更新这些的任务也必须位于动物实体之外。

我们可以尝试将这些历史组合成另一个名为 AnimalHistory 的聚合根。其全部目的是维护动物的历史。但是，这将再次将有关将历史存储到动物之外的其他事物的逻辑转移。可能是像 AnimalProcessingService 这样的服务，感觉我们可能会走向一个乏味的设计。

我希望有另一种选择可以为我们提供更简洁的设计。

Answer 1

这是 Martin Fowler 最近发表的一篇有趣的文章，它可能会解决您对检索时不需要某些东西的一些担忧，称为命令查询职责分离。基本概念是您可以对“查询”(读取)使用与“命令”(保存)不同的“模型”。

http://martinfowler.com/bliki/CQRS.html

仅仅因为你在做 DDD 并不意味着一切都需要包含在适当的域对象中。设计您的域与设计服务和事件等同样重要。我的意思是通过关注“域”需要什么以及满足这些需求的解决方案是什么，让您的域更自然地出现。 DDD 没有严格的方法论，它更像是一种视角选择，而不是正式的设计模式。因此，如果历史对象仅用于保存，则将历史对象作为实体根并不一定是坏事。让与“命令”相关的服务组成正确的逻辑流程，以保存动物和历史。

我还想指出诸如 Animal.UpdateStatus(newStatus) 之类的东西很像 Active Record，您似乎想避免这种情况。