拆分服务 - > Business Objects？

Question

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

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

我正在寻找一种解决方案,以防止未来任何重构的需要.
一种方法可能是将您的服务拆分为多个子服务,并使您的原始服务成为服务外观.因此,例如,您可以使用UserServiceFacade代替大型UserService,该调用将调用委托给PasswordService,RegistrationService,....

我认为这不是一个糟糕的解决方案,但我对此并不太热心,因为:

1. 很难提前确定哪些子服务分开工作; 如果您错过了判断,您可能仍需要向后重构或仅使用一种方法进行服务
2. 如果例如PasswordService和RegistrationService需要通用功能,则重用Business Logic会更加困难

另一个解决方案可能是使用Business Objects(在我的理解中)也可以看到一个子服务,然后每个特定的UseCase一个,所以你可能有BO的像CreateUserBO,CheckPasswordBO,DeleteUserBO,....

我对这种方法更加热衷,因为在我的观察中,它提供了一些优势:

1. BO本身是非常易读的,只有它的合同才需要它; 所有其余的都可以委托给其他BO,单个BO将是简短而重要的
2. 易于重用的功能
3. 更容易更改/切换某个UseCase的实现:只需用Spring注入另一个实现
4. 更容易测试:只需要测试特定的UseCase,可以嘲笑其他BO的代理
5. 协作:如果几个开发人员在处理同一服务时处理不同的BO,则会减少冲突

但我也看到了一些可能的缺点:

1. 一点额外的工作(至少在排序方面)
2. 还有更多的课程会降低项目的可读性吗？
3. 另一个抽象层:需要一个额外的步骤来查找UseCase的实际实现

问题或者更确切的问题(抱歉)是:

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

Answer 1

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

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

希望有帮助。

Answer 2

使用您提到的第一种方法，为什么不直接扩展该服务，而不是创建“外观”呢？在这种情况下，您可以重用超级/原始类中的代码。

我认为，如果以一种可读的方式组织其包结构，那么在任何情况下，拥有许多较小的类肯定比拥有承担大量功能的大型类更可取，因此更容易发生更改。

最后，我认为这两种方法非常相似，要么您最终可以获得高度的代码重用，如果您需要更新结构方面的内容，那么很容易进行全局更改（相对而言），并且也很容易进行具体的实施更改。