领域模型持久化机制的渐进选型：入口→活动记录→数据映射器

如果领域逻辑简单、领域类和数据库表基本一一对应，直接让每个领域对象自己负责与数据库交互，即活动记录，是最省事的选择——可以把它理解成”从行数据入口出发，把领域逻辑逐步加进这个类里”，尤其当从多个事务脚本中发现重复代码时自然演化出来。但随着领域逻辑变得复杂，活动记录会逐渐力不从心：领域类与表的一对一关系会因为把逻辑拆到更小的类中而失效，关系数据库天生不支持继承，导致策略模式等轻量OO技巧很难用上，而且你会希望脱离数据库也能随时测试领域逻辑。这时给领域模型套一层”入口”（行数据/表数据入口）虽然能缓解一些问题，却仍把数据库方案和领域模型耦合在一起，还平添了入口域到领域对象域之间的转换复杂度——作者因此不推荐把入口用作领域模型的首选持久化机制。真正的解法是让领域模型和数据库彻底独立，用一个专门的间接层（数据映射器）负责两者之间所有的存取映射，让双方能各自独立演化——这是最复杂的一种数据库映射架构，但换来了两层的完全解耦。这些持久化机制并不互斥，但首选机制只应该选一个，不要混用导致凌乱；即便以数据映射器为首选，仍可以用数据入口去封装被视为外部接口的表或服务。

结构图：

flowchart LR
  A["领域逻辑简单<br/>类与表一一对应"] -->|复杂度上升| B["活动记录不再够用<br/>(无法用继承/策略等OO技巧)"]
  B -->|加一层入口| C["入口耦合数据库方案<br/>仍有转换复杂度，不推荐首选"]
  B -->|彻底解耦| D["数据映射器<br/>领域模型与数据库互相独立"]