拆分服务 - ＆gt; Business Objects？

Question

我相信我像许多人一样构建我的项目。你有一个数据层（DAO），服务层（服务）和表示层（Spring MVC，Wicket，...）。

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

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

我认为这不是一个糟糕的解决方案，但我对它并不太热心，因为：

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

另一种解决方案可能是使用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

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

我还建议探索Spring Roo - 这会带来一些革命性的东西，就像你不需要DAO图层等那样关注你的层而言。

希望有所帮助。

Answer 2

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

我认为如果以可读的方式组织他们的包结构，那么在任何情况下拥有许多较小的类当然更可取的是具有大量功能的大类，因此更有可能进行更改。

最后我认为这两种方法非常相似，要么你最终都要有高度的代码重用，如果你需要在结构上更新某些东西，那么很容易做出全局变化（相对来说） ），也很容易做出具体的实施变更。

Answer 3

我个人所做的是我总是使用门面来提供服务。逻辑在服务的内部类中，但我提供了该服务的客户端可以调用的接口。

我尽量避免从一开始就把任何逻辑放在外立面上。只是锅炉板代码重定向到正确的代码逻辑。

因此，即使您的服务具有许多功能，外观仍然可以维护。

但是，如果您控制整个源代码库，如果您在一个服务中开始拥有太多功能，则应该毫不犹豫地进行重构和细分。即使您使用多个课程来完成这项工作，从长远来看，明确区分您的服务也会更好。