I find it difficult allying CQRS/ES with the "Out of tar pit" paper architecture.
This architecture implies 4 layers:
- State (state of the application)
- Business Domain (purely functional)
- Control ( all the dirty stuff for making the layers work together)
In my case, the state depends heavily on a database.
With the CQRS/ES in mind, I have a decision engine. The decision engine for producing an event from a command, is the Business Domain, which has to be purely functional.
When a command asks for an Item to be created, the decision engine chooses to accept or not to create an event CreateItem only if the Item is not already existing (simplified for the example).
In theory, I should pass the state of the application as a argument to the Business Domain, so as to decide accordingly.
But in the case of a database, I cannot pass the database as a side-effect free parameter. I feel like I have to perform the query checking the existence of the item beforehand inside the Control layer, and then pass the result of the query on the database to the Business Domain, which will then return an event or not.
The consequence is that I have some business code (the one related to the query and the business logic to perform the checkings) that will be inside the Control layer.
That feels wrong for me as far as I understood the "Out of the tar pit" paper and also CQRS/ES.
The main issue seems for me that the state is huge: it's the whole database.
What is wrong in my reasoning ?