让我们假设我们有单独的读取模型，因此我们仅在写入侧使用存储库，而不在读取侧使用存储库。 （这个问题全都与写方有关）
此外，让我们假设我们的目标之一是完全聚合/实体封装，使其只暴露行为而不显示状态。 （意思是，没有获取者/设定者）
接下来，假设我们不想使用ORM或反射来从存储库中获取聚合内部信息。
很明显，剩下的解决方案之一是聚合本身将其完整状态公开为VO / poco，然后将其移交给存储库。然后，存储库将知道如何将其映射到DAO并保存。
现在，在许多地方，我读到存储库应该自己接受聚合。
问题是：为什么？聚合公开其状态的VO，将其交给存储库，然后让repo根据该状态进行保存，这是怎么回事？
好处是完整而清晰的聚合封装。
答案 0 :(得分：1)
聚集公开状态的VO有什么问题，将其交给存储库，然后让仓库根据它进行保存？
该方法违反了领域建模思想的其他一些假设。
这些假设之一是关键业务逻辑和“管道”应分开。您需要获取聚合的可序列化表示，这是您试图将状态写入稳定存储的事实（如果您将聚合保持在内存中，则完全不需要此步骤）。
第二个假设是使用“对象”为领域建模是一个好主意。如果您使用的是功能方法，那么您当然会保存值，而不是对象。
请记住，这有助于我们记住我们编写的解决方案的背景在过去15-20年中发生了很大变化。对于包含多个会话的长会话的本地化应用程序有意义的模式对于分布式无状态应用程序不一定有意义，反之亦然。
这种模式会导致您牺牲聚合封装
不，它不是-向对象提供先前同意的表示形式的某些信息的副本不会违反封装。例如，请参见Kevlin Henney。
但是，它的作用是需要适合两个不同协作者的接口：关心业务规则的应用程序和关心表示的持久性的存储库。