SPring引导中多个服务bean的设计模式

Question

我正在从事一个Spring Boot服务项目，在这个项目中，我们有多个spring服务bean，它们相互自动连接。

例如：

@Service
public class Service1

@Autowire
Service2, Service3
.
.
.
@Service
public class Service5
@Autowire
Service 4, Service 1

@Repository
public interface Service1Repository extends JpaRepository<Entity1, UUID>
.
.
.
@Repository
public interface Service5Repository extends JpaRepository<Entity5, UUID>

大多数服务bean自动连接到另一个服务bean中，同时将其相应的存储库bean与其他一些bean（ModelMapper、一些应用程序上下文bean）自动连接，有时这会导致循环依赖性问题，有时会导致代码质量检查失败，因为通过构造函数注入自动连接的bean超过9个。

我的问题是，是否有最佳实践或设计模式来构建这些应用程序Spring bean？

Answer 1

我的建议如下：

• 如果可测试性不是您主要关心的问题（即强制执行类级不变量），请不要通过构造函数注入自动装配，请尝试使用字段注入。这有助于代码质量检查。
• 尝试主要围绕模型对您的服务进行分组。例如，对于模型Person，请为模型Person提供一个个性化存储库和一个仅操作Person类型对象的个性化服务。此外，仅从其相应的服务方法中调用存储库方法。
• 对于复杂的业务案例，有专门针对您正在解决的业务问题的服务类。例如，如果您正在实施员工名册应用程序，有一个用于生成名册的服务，另一个用于通知员工他们当前的日程安排，另一个用于将名册导出到Google表格。

您的问题没有详细说明这些服务的意图。如果您评估策略、工厂、构建器或复合设计模式是否对您的案例有帮助，这将是有益的。

Answer 2

我不能确切地说，因为我不知道这些服务到底在做什么。但看起来您有许多“事务脚本”作为服务公开，即在每个服务中都有自上而下的程序类型的计算。在某种程度上，开发人员看到了服务中的重复，并决定将它们自动连接到彼此之间。

服务层基本上可以作为事务脚本，或者将域对象连接在一起，并将它们公开给控制器或其他层。话虽如此，也可以在其他服务中注入服务，但它们太多了，正如您所说，具有循环依赖性似乎是一个问题。

我的最佳猜测是，该项目最初是一个事务脚本，但现在它发展成为需要域模型的东西。也许您应该尝试识别对应于业务逻辑并且可以在不同服务之间重用的对象。这应该会减少服务的数量。

这与其说是设计问题，不如说是架构问题。

如果不进一步了解服务的性质，那就无话可说了。