基于数据源还是聚合根实现Repository模式？哪种实践更优？

• 优先按聚合根划分是Repository模式的核心最佳实践，尤其是在领域驱动设计（DDD）场景下。Repository的本质是封装聚合根的持久化逻辑，让业务/领域层完全不用关心底层数据源细节。比如CarRepository只负责汽车聚合根的增删改查，业务代码调用时只和领域对象交互，根本不用管数据存在DB还是Redis。
• 按数据源划分（如RedisRepository、DbRepository）只适合极简项目场景：比如项目没有明确领域边界，只是做简单数据读写的工具封装。这种方式的问题很明显——会让业务层直接依赖数据源细节，违背了Repository“隔离持久化逻辑”的初衷，后续扩展新数据源或者修改存储方式时，要大量改动业务代码，维护成本极高。
• 如果需要用多种数据源存储同一个聚合根（比如Car的基础数据存在DB，缓存存在Redis），正确的做法是在聚合根Repository内部封装多数据源逻辑，对外仍然暴露统一的CarRepository接口，业务层完全感知不到底层的数据源差异。

优质技术文章推荐 #

• 《Implementing the Repository Pattern Properly》：聚焦Repository模式的本质，明确其是为领域对象服务而非数据源，详细对比不同划分方式的优劣，讲解DDD场景下的落地细节。
• 《Repository Pattern: Not Just for Databases》：强调Repository的抽象性，通过实际案例说明如何通过聚合根划分实现业务与持久化的解耦，避免陷入“数据源驱动”的误区。

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