Architecture 在SOA中从编排层调用服务？

面向服务的体系结构原则指出，服务组合在SOA中是一件重要的事情。但服务松耦合也很重要

这是否意味着编排层应该是唯一允许调用系统中服务的层

正如我所理解的SOA，编排层将所有服务“粘合”到一个软件应用程序中。我试着在图A和图B上描述这一点

两者之间的区别在于，在图A中，应用程序由服务组成，所有逻辑都在编排层中完成。对服务的所有调用都仅从编排层完成。在图B上，应用程序由服务组成，但一个服务调用另一个服务

图B中的架构是否违反了SOA的服务松耦合原则？一个服务可以调用SOA中的另一个服务吗？更一般地说，在服务松耦合、抽象、可重用性、自治性等方面，图A上的体系结构可以被认为优于图B上的体系结构吗

我的猜测是A架构更通用，但它可以在编排层和所有被调用的服务之间添加一些不必要的数据传输

---

假设服务1和服务2下面的所有内容都封装在它们的契约后面，那么它们是松散耦合的。但是，B没有利用业务流程层释放服务1的能力。A和B之间没有明确的对错，但存在权衡。图A需要更多的开发工作，因为B返回到A的细节需要提取到编排层——如果涉及到数据列表，则B需要允许作为标准传入参数集合。然而，这使得svc 1对svc 2一无所知。因此，如果服务由两个不同的团队拥有和管理，那么A将允许这些团队自主工作。例如，如果svc 1是客户信息服务CI，而svc 2是付款服务，则业务流程层可以将CI数据与svc 2缝合在一起，以返回客户姓名及其最新付款数据的列表。对于图A，在编排层中使用内存连接来进行缝合。然后客户端调用业务流程层。使用B，客户机可以直接调用服务1，但是如果您开始允许服务相互调用，那么最终可能会出现一个令人讨厌的依赖关系图，包括重新进入调用的可能性。如果您的团队规模较小，并且同时拥有svc 1和svc 2，那么他们可以跟踪这些依赖项。但是，当您有不同的团队时，您可能会发现B中的依赖关系不容易了解或管理良好。

您的返回键是否已损坏？