域驱动设计、存储库和混合实体

Question

如果存储库在构建过程中相互通信，是否违反了任何领域驱动的设计原则？

例如，用户地址存储库与城市/地区/国家/地区存储库通信以获取数据？

Answer 1

它违反了领域驱动设计，我认为，存储库不应该相互引用。此外，您不应该在存储库和数据库表之间进行1:1的映射。

这就是Aggregate和AggregateRoot的概念。例如，假设在数据库中有两个表：

Order
OrderLine

对于关系1:n，( Order，OrderLine)被定义为聚合，因为OrderLine不能在没有Order的情况下单独存在。在这种情况下，顺序是这个聚合的根。

这样，而不是创建两个存储库：

OrderRepository
OrderLineRepository

使用OrderLine的级联load、insert和delete，您应该只有一个OrderRepository来管理整个聚合

因此，在您的情况下，应该考虑是否存在地址/城市/地区/国家存储库。

希望这对你有所帮助

Answer 2

有几种方法可以解决您的问题：

• 保持2个聚合根之间的紧密关系，并在您对第一个根进行水合时系统地水合第二个根的整个聚合体。这需要第一个存储库与第二个存储库对话，这不会破坏任何分布式分布式设计原则，但可能会在性能方面造成潜在问题。
• 将这两个根松散地链接在一起。这基本上意味着指向被引用根的ID，而不是整个实例。然后，客户端代码或根本身(尽管有人会说后者是不好的做法)将通过调用其repository.
• Realize来从其ID恢复引用的根，这些对象是真正的(不可变的)值对象，不需要ID，并且可以被任何聚合根或实体直接引用，而不会产生进一步的后果。这也意味着这些对象没有存储库。

在选项1和选项2之间进行选择只是一个技术问题，只会影响性能和开发人员的舒适度。选项3更多的是具有可能的业务影响的领域选择。城市、地区和国家是用户可以创建、修改和删除的大型领域实体吗？有没有专门为这些人准备的屏幕？在做出决定之前，您需要与您的领域专家讨论这些问题。

您可能会发现有帮助的链接：

Aggregate Root references other aggregate roots

http://tech.groups.yahoo.com/group/domaindrivendesign/message/8696

Answer 3

我们遇到了同样的问题，ISO货币和ISO国家在我们的系统中。我们发现，我们拥有的几乎每个聚合根(并具有相应的存储库)都需要货币和/或国家实体作为子实体。从数据管理和数据检索的角度来看，这被证明是低效的，所以我们做了以下工作：

1. 仍然保持每个聚合根只有一个存储库的概念(就像Cuong Le的answer above)
2. Maintain国家和货币数据的缓存-当聚合根从数据库中耗尽时，我们使用缓存来检索货币/国家信息

根据我的经验，DDD和蓝皮书是一本无价的指南，但你不必100%准确地采用它，你接受了船上的建议，然后对它进行调整，使其对你有意义。

希望这能帮到你。