Description
System design with messaging must be done carefully and should follow fairly strict principles. One such principle is the difference between commands and events.
Put very simply, a command is an instruction to do something and should be sent (not published) to a specific recipient. Sending to a specific recipient infers using a queue. In AWS world this means using SQS.
An event is a notification that something happened and should be published (not sent) with the publisher not really aware of the subscribers. Publishing infers using a topic. In AWS world this means SNS or possibly Event Bridge.
There is a clear distinction between "send" vs "publish", what those operations do and how they work.
These principles are really important to achieve good system design and the current API doesn't follow these. In the context of the above principles, an "SQS publisher" (as provided by the library) does not make sense (you shouldn't "publish" to a "queue").
Going directly to a proposed alternative, consider one interface with differing methods e.g.
public interface IBus
{
Task PublishAsync<T>(T event, CancellationToken token = default); // SNS or EventBridge Transport
Task SendAsync<T>(T command, CancellationToken token = default); // SQS Transport only
}
Or two different interfaces e.g.
// SNS or EventBridge Transport
public interface IMessagePublisher
{
Task PublishAsync<T>(T event, CancellationToken token = default);
}
// SQS Transport only
public interface IMessageSender
{
Task SendAsync<T>(T command, CancellationToken token = default);
}
This encourages consumers to follow a system design better aligned with correct messaging principles.