正确传递面向服务的体系结构

Question

我不太清楚该怎么表达我的问题，所以我要举一个例子。

比如说你在制作支付处理软件。您实现了面向服务的体系结构，并且您有事件的三个主要阶段

1. 录取，在那里你可以得到新的报酬
2. 核实，在那里你核实。
3. 付款，你结账的地方。

因此，在这个场景中，您有3个服务(处理器)--一个接收处理器、一个验证处理器和一个支付处理器。

我的问题是，谁的工作是将事件从接收处理器传递到验证处理器。验证处理器如何知道何时从接收处理器获取事件。接收处理器是将事件“交给”验证处理器，还是验证处理器查看取食事件并说“已完成”，我现在就接受它？

Answer 1

在这个问题上没有提供太多的信息，比如各个阶段的责任，比如契约或维护的工件/事件。

但是，您有两个选择，轮询和通知。

轮询在高频率的情况下效率很低，但是如果你需要/想要成批地做事情，比如每天或每周，有时是一个很好的选择。

通知在更改后立即将消息从服务1发送到服务2。服务1和服务2之间的耦合程度是令人感兴趣的，并且可能有所不同。

您可以让服务1了解服务2，这是相对紧密的耦合，因为它不一定是服务1's的责任，知道什么服务2需要。

您可以让服务2了解服务1，在服务1中请求对更改(具有某种类型和性质)的订阅，这是更松散的耦合，因为服务2位于服务1的下游，因此已经意识到某些依赖关系。

如果使用中间消息总线，您可以进一步解耦，因为服务1和服务2只知道事件和事件类型，一个发布，另一个订阅，而不是相互了解。

哪个最适合您，取决于问题中没有提供的信息，以及对这些服务是否正确的评估。

当我查看要拥有的服务时，我会考虑一些问题，比如什么服务是记录这个或那个信息(或计算或决策)的权限。如何完成长时间运行的过程？通常使用一个服务负责长期运行的进程的状态，而其他服务则围绕对长期运行状态的更改进行交互(对状态更改执行一些操作，然后更新状态，这会触发其他事情发生)。

但是在我尝试定义服务之前，我喜欢理解生态系统的业务上下文，它涉及到所涉及的业务实体和客户的外部交互角色(以及他们的职责)。