When Thomas Pierrain started a new project with an asset management company, one important requirement was the ability to go back in time to understand why they took decisions that today look strange. At the recent DDD Europe 2018 conference in Amsterdam, Pierrain discussed his experiences when building an event sourced system that included some temporal challenges.
The company wanted to build a system that could provide the whole company with information related to the business. Detailed requirements included the ability to generate reports for a specific date in the past, changing the past by adding retroactive events, and scheduling events in the future.
In the beginning, Pierrain, a consultant at 42skillz, and his colleagues had difficulties getting a grip on the needs of the business, so they had several meetings and workshops to understand the domain, the requirements and what they really meant. The reason for changing the past was that the business found out about things happening after they had happened, and thus had to change their view of the world by adding events retroactively. The reason for scheduling events in the future was that sometimes they knew about things long before they would actually happen, and they didn't want to miss these events, which they had done before.
Although for Pierrain it looked like a system based on event sourcing would be a good fit, the requirement to change the past and the event scheduling made him question it. He therefore checked with the event sourcing community, and the responses, including one from Greg Young, showed approval of his ideas. Young also referred to a blog post he wrote 2014, Event Sourcing and Post/Pre Dated Transactions.
To work with events in the past you can use three projections modes depending on the need:
- "as at" for results at a particular date.
- "as of" for results at a particular date but also taking in account later events that should be applied retroactively.
- "as of until" for results at a particular date, taking in account later events that should be applied retroactively, but only up to a specific date.
A retroactive event has two dates, one for when something happened (actual date) and one for when it was recorded. To create reports in the past you have to consider both dates on an event. For his needs, Pierrain use two terms:
- Viewpoint date, which is the state of the world at a certain time, using "as of until".
- Projection date, which is the date of the report.
This means that when creating a report for June 1, 2017 with a view of the world as it was July 1, 2017 you will use events with an actual date of June 1, 2017, recorded not later than July 1, 2017. An example is a MoneyAdded event that represent an amount of money added to an account on a specific date. To create a report using the previous dates, the following logic will be used:
- An event with an actual and recorded date of June 1 will be added.
- An event with an actual and recorded date of June 2 will not be added.
- An event with an actual date of June 1 and a recorded date of July 1 will be added.
- An event with an actual date of June 1 and a recorded date of July 2 will not be added.
To create retractive events the team decided to use commands to create the events, because they have business logic that must be applied; although Pierrain notes that in some use cases, directly creating the events is more relevant. The solution for events in the future was to schedule a command in the future that would create an event.
Back in 2005 Martin Fowler wrote an article about Temporal patterns that describes the same type of problems that Pierrain experienced.
The planning for DDD Europe 2019 has started but the exact date has not yet been set.