域对象中的持久性注释是一种不好的做法吗？

在我对使用Spring和Hibernate的现有系统进行的最新迭代中，我已经开始在类似的事情上移动。在第一次实现Hibernate模型时，我努力通过数据访问对象将服务类中的应用程序逻辑与持久性逻辑分开。去年构建新系统时，我允许大多数持久性对象用作域对象，因为这是权宜之计。

但是，我正在根据不断变化的业务需求重新设计同一系统，并且我再次倾向于将这些关注点分开。我进入新设计只有几天的时间，但我已经发现自己更喜欢有一个对象来表示内存中关注的对象，而一个单独的基于持久性的对象用于将其状态更改存储到数据库中。例如，我有一个持久性和一个跨交易的并行。LeadActiveLead

我还不相信这是最好的方法，但它在直觉层面上是有意义的。我渴望拥有一组持久性 -- 不可知 - 不，持久性 - 无知 - 一组对象，这些对象在数据库事务中保持内存驻留，而不考虑标准的 CRUD 简化。然而，我明白，最终所有数据库操作都是作为CRUD实现的。两个世界必须碰撞，诀窍在于让它们和谐共舞。

对域对象进行休眠注释？在我看来，这是易于实现与易于维护之间的一个很好的折衷。

我最近在一个相当复杂的系统上工作，它有一个单独的持久层，这是一个巨大的痛苦，对可维护性非常不利。你基本上是在研究YAGNI原则和单一责任之间的冲突。在我看来，YAGNI是更重要的一个（唉，也是经常被忽视的那个）。

我想说的是，在绝大多数情况下，如果你使用的是ORM，那么直接持久化域对象要好得多，除非你有具体的要求来强制持久性实体以不同的方式构建（如果它们具有完全相同的结构，除了象牙塔参数之外，没有理由将它们分开）。

可以肯定的是：始终在单独的服务/DAO层中执行实际的持久性操作（调用ORM函数）！这样，如果您发现需要持久性层，以后就很容易引入它。