This approach entails generating an approximate stream of events for each aggregate so that the stream of events can be projected into the same state representation as in the original implementation. Consider the example you saw in Chapter 7, as repre‐ sented in Table 11-1.

Table 11-1. A state-based representation of the aggregate’s data

We can assume from the business logic perspective that the instance of the aggregate has been initialized; then the person has been contacted, an order has been placed, and finally, since the status was “converted,” the payment for the order has been con‐ firmed. The following set of events can represent all of these assumptions:

{

"lead-id": 12,

"event-id": 0,

"event-type": "lead-initialized",

"first-name": "Shauna",

"last-name": "Mercia",

"phone-number": "555-4753"

},

{

"lead-id": 12,

"event-id": 1,

"event-type": "contacted",

"timestamp": "2020-05-27T12:02:12.51Z"

},

{

"lead-id": 12,

"event-id": 2,

"event-type": "order-submitted",

"payment-deadline": "2020-05-30T12:02:12.51Z",

"timestamp": "2020-05-27T12:02:12.51Z"

},

{

"lead-id": 12,

"event-id": 3,

"event-type": "payment-confirmed",

"status": "converted",

"timestamp": "2020-05-27T12:38:44.12Z"

}

When applied one by one, these events can be projected into the exact state represen‐ tation as in the original system. The “recovered” events can be easily tested by projec‐ ting the state and comparing it to the original data.

However, it’s important to keep in mind the disadvantage of this approach. The goal of using event sourcing is to have a reliable, strongly consistent history of the aggre‐ gates’ domain events. When this approach is used, it’s impossible to recover the com‐ plete history of state transitions. In the preceding example, we don’t know how many times the sales agent has contacted the person, and therefore, how many “contacted” events we have missed.