anchor.diff:  ## Outlook
   
   In this post we described an approach for creating aggregated events from Debezium's CDC events.
  -In a follow-up blog post we may dive a bit more into the topic of partitioning and ...
  -_//TODO: give a glimpse on planned upcoming blog posts..._
  +In a follow-up blog post we may dive a bit more into the topic of how to be able to horizontally scale
  +the DDD creation by running multiple KStreams aggregator instances. For that purpose, the data needs proper
  +re-partitioning before running the topology. In addition, it could be interesting to look into 
  +a somewhat more generic version which only needs custom classes to the describe the two main POJOs involved. 
   
   We also thought about providing a ready-to-use component which would work in a generic way
   (based on Connect records, i.e. not tied to a specific serialization format such as JSON) and
  
positive.code: 
  Concrete examples are:
  
  * **customers and their addresses** which are represented as a customer record aggregate
  storing a customer and a list of addresses
  
  * **orders and corresponding line items** which are represented as an order record
  aggregate storing an order and all its line items
  
  Chances are that the data of the involved domain objects backing these DDD aggregates are stored in
  separate relations of an RDBMS. When making use of the CDC capabilities currently found
  
negative.code:         "topics": "final_ddd_aggregates",
          "mongodb.connection.uri": "mongodb://mongodb:27017/inventory?w=1&journal=true",
          "mongodb.collection": "customers_with_addresses",
          "mongodb.document.id.strategy": "at.grahsl.kafka.connect.mongodb.processor.id.strategy.FullKeyStrategy",
          "mongodb.delete.on.null.values": true
      }
  }
  ----
  