It is often said that Kafka works well with domain driven designs.
Why is it then that Kafka blog posts mostly talk about CQRS or similar - suggesting seperate input and output topics?
It seems like a topic could be about a thing. Why should services 'talk' about that same thing spread out by an implementation detail of who/what is talking?
Isn't this a lot of overhead to protect services from peers that have issues causing them to spam the topic?
I'm hoping for responses that offer pros/cons - why people might think a given thing. Not opinions about the 'right' answer. If this is a better fit for a different SO, I'd appreciate being pointed the right direction.
To summarize
CQRS is a pattern you use within a service (Bounded context), that allows you to implement the command and query sides in separate ways. That is what CQRS is all about.
Event sourcing is an optional pattern that you often see together with CQRS, but it is not a requirement.
I see Kafka as the backbone between services, as the record of truth between services, like how the picture below:
In this case, you use Kafka to pass notifications of what happens in the different services. (Event-driven architecture). But I would not try to use Kafka for request/response communication even though it is possible.
When you aim for a request/response pattern, you typically want a synchronous response, like if the user sends a command to the system. But in general, to reduce coupling you should not send commands between services, better to publish events and let other services react to those events.