java - 拆分服务 -> 业务对象？

Question

我相信我像许多人一样构建我的项目。您有数据层 (DAO)、服务层 (services) 和表示层(Spring MVC、Wicket 等)。

通常，服务开始时非常简单和“简短”。然而，逐渐地，该服务必须支持越来越多的用例，直到一段时间后它变成一个具有许多行和方法并且难以阅读和维护的巨大类。那时你可以决定坚持下去或开始重构，这是一项繁琐且“危险”的工作，需要大量工作。

我正在寻找一种解决方案，以防止将来需要进行任何重构。
一种方法可能是将您的服务拆分为多个子服务，并使您的原始服务成为服务外观。因此，例如，您可以拥有一个 UserServiceFacade，而不是一个大的 UserService，它将调用委托(delegate)给 PasswordService、RegistrationService，...。

我认为这不是一个糟糕的解决方案，但我不太热衷于此，因为:

1. 难以预先定义在哪些子服务中拆分工作；如果你判断错误，你可能仍然需要事后重构，或者有一个只有一种方法的服务
2. 如果例如 PasswordService 和 RegistrationService 需要通用功能，则业务逻辑的重用会更加困难

另一种解决方案可能是使用业务对象，(据我所知)它也可以看作是一个子服务，但是每个特定的用例都有一个子服务，所以你可能有 BO，比如 CreateUserBO、CheckPasswordBO、DeleteUserBO，...。

我对这种方法更感兴趣，因为在我看来，它提供了很多优势:

1. BO 本身是非常可读的，并且只做契约(Contract)要求它做的事情；剩下的可以委托(delegate)给其他BO，一个BO就短小精悍
2. 易于重用的功能
3. 更容易更改/切换某个用例的实现:只需使用 Spring 注入(inject)另一个实现
4. 更易于测试:只需要测试特定的用例，可以模拟对其他 BO 的委托(delegate)
5. 协作:如果多个开发人员在不同的 BO 上工作，那么当他们在同一服务上工作时，冲突会减少

不过，我确实也看到了一些可能的缺点:

1. 一些额外的工作(至少在排序方面)
2. 太多的类会降低项目的可读性吗？
3. 多一个抽象层:需要一个额外的步骤来找到 UseCase 的实际实现

问题或问题(抱歉)是:

1. Business Objects 是这个问题的理想解决方案吗？
2. 您是否同意我上面列出的 BO 的优点/缺点和/或您是否看到其他优点/缺点？
3. 是否有其他(好的)解决方案来防止大型服务破坏您的一天？

Answer 1

我建议您在 Domain Driven Design 上查看这篇文章如果你的申请比大学作业更重要。基本前提是围绕您的实体构建所有内容并拥有强大的领域模型。区分提供基础设施相关事物(例如发送电子邮件、持久数据)的服务和实际执行您的核心业务需求的服务。

我还建议探索 Spring Roo - 就构建层而言，它带来了一些革命性的东西，比如不需要 DAO 层等。

希望对您有所帮助。