title: Microservice input and output domain models
body: <p>I am using Kafka to decouple my services, but I'm having some seconds thoughts on the way services consume and produce inputs and outputs.</p>
  
  <p>If I have a service A, which takes data from some external service out of my control, I am forced to adapt to the data format (domain) that external system provides. Following such practice, my service A pushes its results to a topic in its own format (domain).</p>
  
  <p>Incidentally, I have a service B, which does similar thing to service A, but consumes some other external service, and has its own data format (domain), which it pushes to a separate topic.</p>
  
  <p>Now, the semantics of the data produced by A and B are similar, but not the same. But, next step in the pipeline is a service C, which should consume both what A and B produce, do something with it and spit out the results.</p>
  
  <p>Should C only know how to consume data from one place, which would imply that A &amp; B (and any other ones in the future) need to produce their outputs in C-specific domain? That would mean, if the C consumer ever changes it's domain, A, B, and any other producers will have to change, which I don't like. Also, if I add another consumer, D, for example, that means that A and B, using this analogy, should know that D is also their consumer, which looks horrible to me.</p>
  
  <p>I was thinking that C should be responsible for it's inputs, meaning it has a dependency on A and B models (and any other that might produce their own data).
  It also implies that, when a new source is added, C must be changed to include that data as well.</p>
  
  <p>Effectively, I'm leaning towards ManySources-OneSink component, instead of OneSource-ManySinks.</p>
  
  <p>Are there any preferred practices?</p>