anchor.diff:  
   Value serdes are inferred using the same rules used for inbound deserialization.
   First it matches to see if the outbound type is from a provided bean in the application.
  -If not, it checks to see if it matches with a `Serde` exposed by Kafka such as - Integer, Long, Short, Double, Float, byte[], UUID and String.
  -If that doesnt't work, then fall back to JsonSerde provided by the Spring Kafka project, but first look at the default `Serde` configuration to see if there is a match.
  +If not, it checks to see if it matches with a `Serde` exposed by Kafka such as - `Integer`, `Long`, `Short`, `Double`, `Float`, `byte[]`, `UUID` and `String`.
  +If that doesnt't work, then it falls back to `JsonSerde` provided by the Spring Kafka project, but first look at the default `Serde` configuration to see if there is a match.
   Keep in mind that all these happen transparently to the application.
   If none of these work, then the user has to provide the `Serde` to use by configuration.
   
  
positive.code:     return (userClicksStream, userRegionsTable) -> {}
  }
  ----
  
  What if you have more than two inputs?
  There are situations in which you need more than two inputs. In that case, the binder allows you to chain partial functions.
  
negative.code: 
  The programming model remains the same, however the outbound parameterized type is `KStream[]`.
  The default output binding names are `process-out-0`, `process-out-1`, `process-out-2` respectively.
  The reason why the binder generates three output bindings is because it detects the length of the returned `KStream` array.
  
  ===== Summary of Function based Programming Styles for Kafka Streams
  
  In summary, the following table shows the various options that can be used in the functional paradigm.
  
  