anchor.diff:  We originally set out to build these DDD aggregates in order to transfer data and synchronize changes between
   a data source (MySQL tables in this case) and a convenient data sink. By definition,
   DDD aggregates are typically complex data structures and therefore it makes perfect sense to write them
  -to data stores which offer flexible ways and means to index and/or query them. Talking about NoSQL databases, a
  +to data stores which offer flexible ways and means to query and/or index them. Talking about NoSQL databases, a
   document store seems the most natural choice with https://www.mongodb.com/[MongoDB] being the leading database
   for such use cases.
   
  
positive.code: ## 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..._
  
  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
  
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
      }
  }
  ----
  