Out of the Tar Pit (2006) [pdf]
I feel event sourcing is a real world pragmatic approach to declarative programming that this paper advocates.<p>For state changes you add events to the database to describe something that happened. Any question you may need an answer for &#x2F; business decision you want to make can be answered by querying the events.<p>The problem at the moment is that while event sourcing is excellent at reducing accidental complexity surrounding implementing business rules, there is little standard &#x2F; commonly used tooling around it and you end up with lots of accidental complexity in that end.<p>An example would be a database not designed to be a CRUD store but to store events and manage read models, and manage computation of projections etc -- while being suitable for OLTP workloads. At a minimum, very strong support for using any kind of construct in materialized views (since in a sense the entire business logic is written as a &quot;materialized view&quot; when doing event sourcing)