design-patterns - 服务层模式——我们能否在特定情况下避免使用服务层？

Question

我们正在尝试使用服务层模式实现一个应用程序，因为我们的应用程序也需要连接到其他多个应用程序，并且在网络上进行谷歌搜索，我们发现了这个演示图形的链接，用于应用“正确”的方式图案:

martinfowler.com - Service Layer Pattern

但是现在我们有一个问题:如果我们的系统需要实现一些业务逻辑，只针对我们的应用程序(比如系统本身的一些维护数据)，而我们不需要与其他系统共享，该怎么办？基于此图:

看起来，没有必要仅仅为此实现一个服务层；避免服务层，而只是从用户界面到业务层(例如)会更实际。在这种情况下，实现服务层模式的正确方法应该是什么？对于像我告诉你的那样的场景，您对我们有什么建议？

提前致谢。

Answer 1

“服务层”只是域逻辑的抽象。抽象可以是任何程度的，包括透明的。

术语“层”具有误导性。我认为马丁本人会同意最好将其称为上下文边界(来自领域驱动设计)。这意味着您可以拥有许多服务层来不同程度地抽象您的领域。与您向集成网关公开的服务层相比，您向 UI 公开的服务“层”API 在您的域中可以做更多的事情。

不过，我建议按照功能轮廓分解这些服务 block 。 (例如，用于批量导入数据的一组服务和用户通常与之交互的一组服务应该几乎完全独立。)如果您需要将 API 公开给您希望与您交互的另一个应用程序，则可以采用这种方式就像用户可以使用与 UI 相同的 API 完全相同的方式。