在领域驱动设计（DDD）的实践中，领域对象携带持续层代码，例如通过使用Active Record模式，通常被视为一种反模式。Active Record模式主要通过在领域模型对象中直接包含数据库访问方法，使得对象可以自我保存、删除或者加载自身状态，从而简化少量应用中的数据访问任务。然而，这种模式在大多数情况下并不符合DDD的原则，原因如下：

1. 职责混淆 DDD强调领域逻辑的纯粹性，领域对象（如实体与值对象）应仅专注于业务逻辑，不应承担任何技术职责，如数据的持久化。领域对象应该干净、单一职责，只负责表达领域概念、业务规则和它们之间的交互。而Active Record模式将数据访问与业务逻辑混为一谈，使得领域模型失去了清晰的职责边界，导致领域逻辑容易被复杂化和污染。

2. 可测试性降低 当领域对象与数据库操作紧密耦合时，单元测试变得更为复杂。为了测试领域逻辑，需要初始化数据库连接、创建数据库记录等额外的准备工作，这不仅增加了测试的成本，还可能因为测试依赖于外部环境而变得不稳定。在DDD中，提倡通过模拟（Mocking）依赖来隔离领域逻辑，使其可以独立于外部系统进行测试。

3. 可维护性和可扩展性降低 由于领域对象与数据库操作紧密耦合，任何数据库架构的变动都可能影响到领域模型。例如，当需要从关系型数据库迁移到NoSQL数据库时，领域对象必须做出相应的调整。此外，如果想在不改变领域逻辑的情况下更改持久化策略（如从直接SQL操作改为使用ORM框架），也会遇到困难。这降低了系统的可维护性和可扩展性。

4. 违反开闭原则 根据SOLID原则中的开闭原则，软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。Active Record模式下，如果要添加新的数据访问逻辑，往往需要修改现有领域对象，这违背了开闭原则。而在DDD中，通常通过领域服务或应用服务来处理数据访问逻辑，这样可以保持领域对象的独立性和封闭性。

总之，在DDD中，推荐的做法是将领域模型与基础设施关注点（如持久化、外部系统集成等）分离，以便保持领域模型的专注度和纯净度。可以采用仓库模式（Repository Pattern）来封装数据访问逻辑，同时使用工厂模式（Factory Pattern）和领域事件（Domain Events）等机制来丰富领域模型的行为和交互，从而构建更加健壮、灵活和可维护的系统。这些模式有助于在保持领域逻辑清晰简洁的同时，简化复杂的持久化和数据管理任务。