拆分服务 - >业务对象？
2022-09-02 22:35:28
我相信我像许多人一样构建我的项目。你有一个数据层（DAO），服务层（服务）和表示层（Spring MVC，Wicket等）。
通常，服务开始时非常简单和“简短”。然而，逐渐地，服务必须支持越来越多的用例，直到一段时间后，它成为一个巨大的类，有许多行和方法，并且难以阅读和维护。那时，你可以决定坚持下去，或者开始重构，这是一项繁琐而“危险”的工作，可能需要很多工作。
我正在寻找一个解决方案，如何防止将来需要任何重构。
一种方法是将服务拆分为多个子服务，并使原始服务成为服务外观。因此，例如，您可以拥有一个UserServiceFacade，而不是一个大型UserService，它将调用委托给PasswordService，RegistrationService，... 。
我认为这不是一个糟糕的解决方案，但我对它不太热衷，因为：
- 难以提前定义在哪些子服务中拆分工作;如果你误判了，你可能仍然需要向后重构，或者有一个只有一种方法的服务，例如
- 业务逻辑的重用可能会更加困难，例如，如果密码服务和注册服务需要通用功能
另一种解决方案可能是使用业务对象，（在我的理解中）也可以看到一个子服务，但每个特定的用例一个，所以你可能有BO，如CreateUserBO，CheckPasswordBO，DeleteUserBO，... 。
我对这种方法更感兴趣，因为在我看来，它提供了相当多的优点：
- BO本身非常可读，并且只与它的合同要求它一起做;其余的都可以委托给其他BO，单个BO将很短，切中要害
- 易于重用的功能
- 更容易更改/切换某个用例的实现：只需使用Spring注入另一个实现
- 更易于测试：只需要测试特定的用例，委托给其他BO可以被嘲笑
- 协作：如果多个开发人员在不同的BO上工作，那么当他们在同一个服务上工作时，冲突就会减少
然而，我也看到了一些可能的缺点：
- 有点额外的工作（至少在排序术语中）
- 更多的类可能会降低项目的可读性？
- 另一个抽象层：需要一个额外的步骤来找到用例的实际实现
问题或更确切地说是问题（抱歉）是：
- 业务对象是此问题的理想解决方案吗？
- 您是否同意我上面列出的BO的优点/缺点和/或您是否看到其他优点/缺点？
- 有没有其他（好的）解决方案来防止大型服务毁了你的一天？
