anchor.diff:  4. Journal is replayable to rebuild the state of the application at any point in time
   5. Journal groups domain events by an ID to capture the current state of an object (an Aggregate from DDD parlance)
   
  -[.text-center]
  -image::/images/2020-02-06-event-sourcing-vs-cdc/figure02.png[]
  -[.text-center]
  +[.centered-image.responsive-image]
  +====
  +++++
  +<img src="/images/2020-02-06-event-sourcing-vs-cdc/figure02.png" style="max-width:100%;" class="responsive-image">
  +++++
   *Figure 2. Representation of Event Sourcing Materializing an Object*
  +====
   
   Additionally, Event Sourcing implementations often have these characteristics:
   
  
positive.code: 
  Taking a quick step back, Event Sourcing and Change Data Capture are solutions that can be used to build distributed systems (i.e. microservices) that are Reactive. Microservices should react to an ever-changing environment  (i.e. the cloud) by being resilient and elastic. The magic behind these abilities is being message and event driven. To find out more, I advise you to read the https://www.reactivemanifesto.org/[Reactive Manifesto].
  
  [.text-center]
  image::/images/2020-02-06-event-sourcing-vs-cdc/figure01.png[]
  [.text-center]
  *Figure 1. Attributes of a Reactive System, per the Reactive Manifesto*
  
  == Shared Goals for Event Sourcing and Change Data Capture
  
  
negative.code: 
  Event sourcing mimics how a database works, but at the application-level. Per Figure 2, the figure could be updated to represent a database as shown in Figure 3 with roughly the same design.
  
  [.centered-image.responsive-image]
  ====
  ++++
  <img src="/images/2020-02-06-event-sourcing-vs-cdc/figure03.png" style="max-width:100%;" class="responsive-image">
  ++++
  *Figure 3. Representation of Database Transaction Materializing a Table*
  ====
  
  The comparison between Figure 2 and Figure 3 will become more relevant as we dive deeper into how Event Sourcing and Change Data Capture compare to each other.
  
  