我认为，在分布式系统体系结构中，人们应该更喜欢“智能端点和哑管道”。
为described by Martin Fowler，并在other articles中进行了详细说明。
我的问题是，使用AWS SNS订阅过滤器的功能是否会违反主体，还是该主体更多地是避免在消息总线之类的集中所有消息路由？
举一个更具体的例子，假设我有服务A向SNS主题发送消息。该主题有3个消费者（B，C，D），但是只有三个消费者（D）中的一个有条件地感兴趣。
如我所见，在这种情况下，我有3个选择：
- 不要将服务D订阅该主题，而是使用另一种机制（例如，通过AWS SQS队列进行点对点消息传递），其中生产者（服务A）仅在评估条件逻辑之后才将消息放入队列。感觉特别糟糕，因为就服务责任和凝聚力而言，这将意味着关于服务D是否感兴趣的逻辑决定取决于服务A。
- 使用主题并使服务D在丢弃不符合其条件的任何消息之前先使用所有消息。对我来说似乎可以接受，逻辑保持集中，服务D保持其凝聚力，但是由于所有消息都已传递，并且某种程度上从服务D的角度来看是“无用的”，因此服务D不那么优雅。
- 利用消息传递基础结构的一些更高级的功能，例如SNS订阅筛选器，它将确保除非满足条件，否则不会将消息从服务A传递到服务D。再次，这确实遭受了一些关于服务D的固有知识的了解，这些知识不是直接存储在服务D内，而是存储在某个地方，例如定义基础结构或通过AWS控制台的terraform文件或外壳文件中的一些API调用。保持服务A和D干净且“幸福”（？），不知道消息正在进行的过滤。
基于这些折衷，我觉得选择2或3可能是个不错的方法，但我会稍微想尝试一下选择3，因为我认为它很雅致，但是对于这种方法是否违反了最佳实践却有些不安。剩下的“管道”哑巴。