Java 正确实现复杂服务层

我有以下情况：

三个具体的服务类实现一个服务接口：一个用于持久性，另一个用于通知，第三个用于向特定操作添加点（游戏化）。该接口大致具有以下结构：

public interface IPhotoService {
   void upload();
   Photo get(Long id);
   void like(Long id);
   //etc...
}

我不想将这三种类型的逻辑混合到一个服务中（或者更糟糕的是，在控制器类中），因为我希望能够毫无问题地更改（或关闭）它们。当我必须向控制器中注入一个具体的服务来使用时，问题就出现了。通常，我创建了第四个类，名为ApplicationNamePhotoService，它实现了相同的接口，充当其他三个服务之间的包装器（中介器），从控制器获取输入，并相应地调用每个服务。虽然这是一种有效的方法，但它创建了大量样板代码

这是正确的方法吗？目前，我还没有发现更好的方法，尽管我非常希望知道是否有可能以声明方式（在上下文中）声明执行序列，并向控制器注入动态生成的包装器实例

---

另外，在这三个服务之间缓存一些东西也不错。例如，所有人都在使用DAO，也就是说，有时反复对DB进行相同的调用。如果所有的逻辑都集中在一个本来可以避免的地方，但是现在。。。我知道可以启用一些基于请求或会话的缓存。你能给我推荐一些示例代码吗？顺便说一句，我使用Hibernate作为持久性部分。是否已经提供了一些缓存（可能，如果它们驻留在同一事务或其他事务中，那么我就完全失去了这个缓存）

服务层应该由具有方法的类组成，这些方法是属于同一事务的操作的工作单元。听起来像是在混合服务类，而它们可能在同一个类和方法中。您也可以在需要时将服务类相互注入，而不是创建另一个“中介”

“混合三种类型的逻辑”是完全可以接受的，事实上，如果它们形成预期的用例/工作单元，则更可取

---

我希望使用缓存，我相信它与hibernate集成得很好。

你是说一个接口有三个实现吗？嗯，不是真的。如果我用一门服务课来做这件事，那会是一团意大利面条。我不是说只有一门课。代码应分为工作单元。