仓储模式：解耦领域逻辑与持久化逻辑，降低更换数据库的代价

如果业务逻辑代码里直接混入了基础层的数据处理逻辑（比如直接操作数据实体、拼SQL），基础层的实现细节就会渗透进领域层，让领域逻辑和数据处理逻辑紧耦合，违反”外层依赖内层”的依赖原则，脱离聚合业务规则控制的数据修改也容易导致数据不一致。这种紧耦合的真实代价在技术升级或更换数据库时会集中爆发：因为业务逻辑和数据处理逻辑绑死在一起，换库意味着要把两者重新剥离适配，成本极高、甚至可能要重写核心业务逻辑，这正是很多企业明知技术债缠身、却始终不敢升级技术体系的根本原因。仓储模式就是为了解决这个问题：在领域层和基础层之间插入一层”仓储”，仓储接口面向领域层暴露数据访问能力，仓储实现负责具体的持久化细节；领域层的业务逻辑只面向仓储接口编程，需要持久化时把DO对象转成PO对象交给仓储接口即可，完全不需要关心底层数据库具体是怎么实现存储的。这样一来，日后如果要更换数据库，只需要调整仓储实现代码去适配新数据库，只要仓储接口本身不变，领域层的任何业务逻辑代码都不用动——仓储模式本质上是面向接口编程的依赖倒置（DIP）在DDD持久化场景里的具体应用，用一层可替换的适配层，把易变的基础设施实现和稳定的核心业务逻辑彻底隔离开。