在浏览了多个堆栈溢出帖子和博客文章后，我做出了我们需要 UnitOfWork design 的决定。模式以在将域对象写入各自的存储库时保持事务完整性。
但是，我们在读取/搜索存储库时不需要这种完整性。鉴于此，将存储库和工作单元的用途分开是一个好的设计吗，前者仅用于读取域对象，而后者仅用于创建/写入/刷新/删除域对象？
最佳答案
Eric Evans，领域驱动设计:
Implementation (of a repository) will vary greatly, depending on the technology being used for persistence and the infrastructure you have. The ideal is to hide all the inner workings from the client (although not from the developer of the client), so that the client code ill be the same whether the data is stored in an object database, a relational database, or simply held in memory....
The possibilities of implementation are so diverse that I can only list some concerns to keep in mind....
Leave transaction control to the client. Although the REPOSITORY will insert and delete from the database, it will ordinarily not commit anything. It is tempting to commit after saving, for example, but the client presumably has the context to correctly initiate and commit units of work. Transaction management will be simpler if the REPOSITORY keeps its hands off.
那就是说；我特别提请您注意上述讨论中的一个重要短语:数据库。这里的基本假设是所有被修改的聚合都以这样一种方式存储，即工作单元可以原子地提交。
如果不是这种情况——例如，如果您将聚合存储在不 promise 对多个文档进行原子更新的文档存储中，那么您可能需要考虑在模型中明确地进行这种分离，而不是试图掩饰您正在尝试协调多个提交的事实。
为您的读取用例使用一组存储库是完全合理的，这与您的写入用例中使用的存储库不同。换句话说，当我们有不同的语义时，我们应该有一个不同的接口(interface)，其实现可以根据需要进行调整。
关于repository - DDD : Repository to read and Unit Of Work to write?，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/48904114/