DDD架构下集成测试是否应复用持久化库访问数据库？

Great question—this is a common dilemma when setting up full-stack integration tests for DDD-based systems, and the short answer is: reuse your existing DDD.IdentityAccess.Persistence.Sql class library. Here's why, along with some best practices to make this work cleanly:

为什么复用是更好的选择 #

• 避免冗余工作，降低风险：你已经有一套经过生产验证的IUserRepository实现，它和业务代码的数据库交互逻辑完全一致。新建领域无关DAL意味着要重复编写SQL查询、数据映射、数据库连接代码——这些额外工作很容易引入bug（比如字段名不匹配、数据类型处理错误），导致测试结果不可靠。
• 保证测试与生产逻辑对齐：使用和应用程序相同的持久化层，能确保测试中的查询逻辑和业务层的写入逻辑完全匹配。如果单独建DAL，测试查询可能无法反映领域层实际使用的数据结构或逻辑，进而出现误判。
• 集成测试本就需要跨层依赖：和单元测试的隔离性要求不同，集成测试的核心目标就是验证多组件（API→领域→持久化）的协作是否正常。在这里引入领域和持久化库的依赖不是缺陷，恰恰是测试要验证的核心场景。

如何干净地复用 #

为了让测试代码更易维护，复用持久化层时可以遵循这些做法：

• 在测试中直接实例化SQL仓库：在集成测试项目中添加对DDD.IdentityAccess.Persistence.Sql的引用，使用和测试环境API相同的数据库连接字符串，创建具体实现类（比如SqlUserRepository）的实例。然后调用它的方法（如GetById或FindByEmail）来验证用户是否创建成功。
• 用测试工具类封装仓库调用（可选）：如果想让测试代码和仓库接口的耦合度低一点，可以创建一个简单的测试工具类（比如DatabaseUserVerifier），内部用仓库实现来完成验证逻辑。这样后续如果仓库接口变更，只需要更新这个工具类，不用修改所有测试用例。
• 聚焦业务结果而非实现细节：哪怕使用了持久化层，测试也要围绕业务结果展开：“调用CreateUser接口后，数据库中存在符合预期邮箱/名称的用户”。不要去测试仓库本身的逻辑——那是持久化层单元测试的职责。

什么时候考虑新建DAL？ #

只有当你的持久化层和领域逻辑耦合过紧，导致在测试中使用它需要依赖复杂的领域服务时，新建独立DAL才可能有意义。但在设计良好的DDD系统中，仓库通常是轻量级的，只负责数据访问，所以这种情况很少见。

内容的提问来源于stack exchange，提问作者DmitriBodiu