问关于分层架构和持久化层

EN

我想你要找的是存储库模式。其思想是实现任何与持久化相关的方法，而不是在域对象内，也不是在某个类似于上帝类的“数据存储”对象中，而是在存储库对象中实现，这些方法以1:1的方式对您的域实体进行结构。存储库可以看作是域对象和持久化层之间的一个层。

因此，例如，如果您有一个User对象，也有一个存储库对象UserRepo，它包含对通常CRUD方法的抽象，或者对User对象可能包含其他与持久性相关的操作。UserRepo可能只是一个接口，所以一个特定的持久性感知实现("UserRepoImpl")可以被UserRepoMock之类的东西模拟出来进行测试。

这对你的问题意味着什么？

但是，随着应用程序最终将变得更大，想象一下应用程序层和持久层之间的边界接口也在增长，一旦实现的方法污染了它，它代表了持久性机制上所有可用的操作。

是的，当应用程序增长时，将有更多的域实体，因此存储库层将增长。但不存在“污染”--回购层正是所有持久性操作的归属所在。

这不是违反ISP的行为吗？

系统中需要访问持久性机制的任何部分只需要依赖于它处理的域实体的回购接口。它不需要依赖于其他域实体的repos。所以不，ISP没有被违反，正好相反。

做我必须将与持久化相关的对象注入域对象，对吗？

如果域对象包含需要访问持久性层(如User.getAllPosts())的方法，则必须在构建时将存储库对象注入其中，或者在调用(User.getAllPosts(postRepository))时传递它。

这是否违反了“清洁架构”中的依赖规则？

不，因为域对象只使用接口，因此不存在从域层到存储库层的直接依赖关系。在上面的示例中，User对象将依赖于接口PostRepo，而不是PostRepoImpl。也请参阅清洁建筑，关于“跨越边界”的一节。

这取决于事物的结构。它可以有一个持久化层的1k方法，并有一个客户端使用它们的所有。它可能不会完全平等地使用它们，但这与此无关。就ISP而言，这是很好的。通常，随着应用程序的增长，接口会根据不同的业务对象被分割成多个接口，因此您不会有超大的接口和文件。