3

假设您有一个需要 2 个服务的应用程序，例如。Application, Service1,Service2

您是否应该按照这种洋葱架构构建额外的间接级别并将其中一个服务提升为应用程序服务，并将另一个降级为域服务。

或者你应该Application直接连接到两者Service1吗Service2？

通过另一个级别的间接，您可以减少对层的依赖Application，尤其是对外部服务，例如。'Paypal'、'Facebook'、'Cyber​​Source' 并创建更适合您的编程范式的应用程序服务适配器。毕竟，让所有开发人员熟悉所有这些广泛多样的 API 确实不利于生产力。Façade/Adapter 将使事情更容易开发，同时保护应用程序免受基础设施变化的影响。例如。该公司在 Cyber​​Source 上失败了，决定改用 Paypal，幸运的是，您的应用程序被屏蔽了，您只需要更改适配器即可。

也就是说，适配器肯定会造成不灵活。随着应用程序复杂性的增加，适配器也变得泄漏。那么您可能会遇到 3 个问题：泄漏抽象、惰性层（由于有太多孔而做得不够的层）以及违反通用闭包原则，因为任何时候您需要更改 UI，您不仅要修改您的应用程序，还有您的适配器。

当Service2已经是同一家公司的内部服务时会发生什么？你还应该为每个子系统创建一个适配器吗？如果你的团队很小怎么办？如果您拥有数十个拥有不同技术的团队怎么办？是否有关于添加另一层间接与直接调用服务的适当性指导？

4

1 回答 1

2

我认为您应该设计您的应用程序，使其依赖于对您的应用程序方便的接口，而不考虑使用外部服务的任何考虑。您使用适配器/外观的想法是一个很好的想法，但我认为没有任何理由Service1与Service2.

如果我的应用程序正在制作小部件，那么我应该调用MyService.MakeWidget(args);这个操作协调行为或 2 个不同的外部服务的事实是一个实现细节。

我认为便利因素比替换外部依赖项的目标更重要（尽管两者都由 OA 启用）。方便的界面以间接为代价改善了应用程序的叙述。

于 2013-09-18T15:42:51.543 回答