我有一个业务逻辑，我觉得应该属于域类。但逻辑应该以持久化到数据库结束，这显然不应该是域类的一部分。那么这是什么意思;这种情况是否会强制我将逻辑放入服务中？或者至少是一个引用域类逻辑方法的服务，然后持久化到数据库..（？）
例如，我想将交易发布到证券账户中。许多验证逻辑仅在帐户字段内部，并且看起来这个逻辑应该在域类中。但是我需要一个AccountTransactionService，它只调用域类的逻辑，接收是否执行事务的真/假，然后保存对象（如果已更改）。似乎会有许多Service类只进行这种类型的“转发”方法，然后根据结果进行保存。但也许这是一种非常典型的服务性质？
只是寻找一些建议，因为我不习惯编写服务类，这很好地反映了。除了重构域类中对持久性逻辑的依赖之外，我应该为Service类考虑其他什么目的？
顺便说一下，我只是在编写供个人使用的应用程序。因此，我不必仅仅为了它而尊重所有指南。
答案 0 :(得分：1)
敏捷。
在典型情况下，如果您有很多逻辑位于域逻辑和强制执行逻辑之间的边界，那么可以使用所谓的“应用服务”，但。你要编写大量几乎没有这样做的复制粘贴服务。如果他们什么都不给你，你就不应该遵循任何“最佳实践”。
这是一个有趣的话题，并且非常依赖于特定情况，请您分享一些代码以解决具体问题？