遍历集合

Question

做一些围绕领域驱动设计的阅读，似乎你应该通过遍历聚合根来访问聚合中的所有实体。

但是，在同一时间，你应该真正尝试和封装你的数据，使属性/字段是保护或私人。

因此，我的问题是：如果这些字段是受保护的/私人的，你应该如何遍历聚合？

我现在设置它的方式如下所示：我将我的域模型的所有属性标记为内部，并将“设置”标记为受保护的方法。这样，模型外部至少没有任何东西可以访问属性，但模型中的对象可以访问其他对象属性，我仍然只允许从对象本身中设置属性。

即使我这样做了，我仍然觉得这应该只适用于其他聚合实体的属性（我的意思是，客户的“名称”仍然是私人的，但他们的“订单”应该标记为内部允许客户 - >订单 - >等）

有没有人有任何指导呢？

编辑：

，让我试着给出一个更具体的例子的问题： 我在我的对象图两个对象：书架和图书。让我们说为了这个例子，Bookshelf是聚合根，并且Books存储在书架上，所以只是聚合中的实体（Bookshelf有书籍集合）。

我想写一个方法来添加一本新书到书架。遵循DDD最佳实践，我相信我应该在书架类上编写一个方法，例如AddBook（Book book）。

但是，如果业务要求不能将具有相同标题的书籍添加到书架上，该怎么办？我希望Bookshelf.AddBook方法中的某些逻辑能够检查书籍集合，以确保本书不存在。

现在的问题是，我不能这样做，因为我已经以很好的封装方式编写了Book对象，并且其“名称”属性不能公开访问。

我知道这是一个颇为人为的例子，但我希望能更好地说明问题。我现在也意识到，这不仅仅是一个DDD问题，而是一个实际的OO封装。我确信必须有一个非常普通的，简单的方法来解决我想要做的事情，并且我正在大力推翻它。

Answer 1

父母与子女之间存在暴力，暴露属性没有任何错误。儿童财产暴露于父母，但由于他们之间的密切关系和相互依存关系，它不会破坏封装。

换言之，向Bookhelf公开Book的名称属性没有任何错误，但是将Book的名称暴露给其他聚合是错误的（根据DDD最佳实践）。揭露可修改的书籍集合也是错误的。公开只读集合时应谨慎 - 它可能是破解封装的标志。

这是回答您的问题吗？

Answer 2

Visitor pattern是典型的遍历机制。