仅仅为了重构持久性逻辑而编写服务？

Question

我有一段业务逻辑，我觉得它应该属于一个领域类。但是逻辑应该以持久化到数据库结束，这显然不应该是域类的一部分。那么这是什么意思;这种情况会强制我将逻辑放入服务中吗？或者至少是引用领域类的逻辑方法的服务，然后持久化到数据库..（？）

例如，我想将一笔交易记入证券账户。许多验证逻辑仅在帐户字段内部，因此该逻辑似乎应该在域类内部。但是我需要一个 AccountTransactionService，它简单地调用域类的这个逻辑，接收一个关于是否执行事务的真/假，然后在更改时保存对象。似乎将有许多服务类只执行这种类型的“转发”方法，然后根据结果进行保存。但也许这是一种非常典型的服务性质？

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

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

Answer 1

保持敏捷。

在典型情况下，有这样的服务是可以的，所谓的“应用程序服务”，但是如果你有很多逻辑位于域逻辑和强制持久性逻辑之间的边界上您编写大量几乎不执行此操作的几乎复制粘贴服务。如果它们对您没有任何帮助，您不应该遵循任何“最佳实践”。

这是一个有趣的话题，并且非常依赖于特定情况，您能否分享一些代码以解决具体问题？