编写服务只是为了重构持久性逻辑

我有一段业务逻辑，我觉得它应该属于一个域类。但是逻辑应该以持久化到数据库结束，而且这显然不应该是域类的一部分。那么这意味着什么呢；这种情况会迫使我把逻辑放在服务中吗？或者至少是一个引用域类的逻辑方法，然后持久化到数据库的服务。。（？）

例如，我想将交易过账到证券账户。许多验证逻辑只在account字段内部，因此似乎这个逻辑应该在domain类内部。但我需要一个AccountTransactionService，它只需调用域类的逻辑，接收是否执行事务的true/false，然后在更改时保存对象。似乎会有许多服务类只对方法进行这种类型的"转发"，然后根据结果进行保存。但也许这是一种非常典型的服务性质？

只是寻求一些建议，因为我不习惯编写服务类，这很好地反映了这一点。除了从域类重构出对持久性逻辑的依赖之外，我还应该考虑Service类的其他用途吗？

顺便说一句，我只是为个人使用编写应用程序。所以我真的不必为了它而尊重所有的准则。