假设您有一个需要2项服务的应用程序，例如。 Application，Service1，Service2
您应该构建一个额外的间接级别并将其中一项服务提升为应用程序服务，并将另一项服务降级为域服务，请遵循此onion architecture。
或者您应该Application直接连接到Service1和Service2吗？
使用另一个间接级别，您可以减少对Application层的依赖，尤其是对外部服务，例如。 'Paypal'，'Facebook'，'CyberSource'并创建更适合您的编程范例的应用程序服务适配器。毕竟，所有开发人员都熟悉所有这些广泛使用的API，这对生产力是非常不利的。外观/适配器将使应用程序更容易开发，同时保护应用程序免受基础结构变化的影响。例如。该公司没有使用CyberSource，而是决定使用Paypal，幸运的是，您的应用程序已被屏蔽，您只需要更换适配器而不需要其他任何内容。
也就是说，适配器肯定会产生不灵活性。随着应用程序的复杂性增加，适配器也会变得泄漏。那么你可能有3个问题：漏洞抽象，一个懒惰的层（由于漏洞太多而无法做到足够的层），以及违反常见的闭包原则，因为任何时候你需要更改UI，你不仅要修改你的应用程序，还有适配器。
当Service2已经是同一家公司内部的服务时会发生什么？你还应该为每个子系统创建一个适配器吗？如果您的团队很小，该怎么办？如果您拥有数十个拥有各种技术的团队，该怎么办？对于添加另一层间接而不是直接调用服务有什么指导吗？
答案 0 :(得分：1)
我认为你应该设计你的应用程序，使其依赖于方便的应用程序接口，而不考虑使用外部服务的任何考虑因素。您对使用适配器/外观的想法很好，但我认为没有理由以Service1的方式处理Service2。
如果我的应用程序正在制作小部件，那么我应该只调用MyService.MakeWidget(args);此操作协调行为或2个不同的外部服务这一事实是一个实现细节。
我认为便利因素比替代外部依赖性的目标更重要（尽管两者都是由OA启用的）。方便的界面以间接为代价改进了应用程序的叙述。