Hi Gregory. Thank you so much for your thoughtful response.
I am not sure if I understand it completely, but I will try to respond to the best of my knowledge.
State management isn’t trivial, I am fully aware of that. I have done model based state machine simulation for many years, and developed requirementsascode with that in mind. I want to take that burden of the programmer, because I think it’s a major source of complexity in many applications.
Think of a UseCaseModel as the (simplified) definition of a state machine. Think of the UseCaseModelRunner as the runner of a state machine. A runner of a state machine does not have to remember all the states it passed through, but only the last one. That’s exactly the behavior of the UseCaseModelRunner right now.
So if you send the same event to the UseCaseModelRunner twice, it may react differently, depending on your position in the flow. That “state checking” is NOT done by the code using requirementsascode! It is part of the requirementsascode library.
The UseCaseModelRunner will call the systemReaction that is defined by the code using the library. The systemReaction is a method that knows NOTHING about the other steps. It does not know anything about the state the UseCaseModelRunner is in.
So if the systemReaction is “savePaymentDetails”, for example, the method will only do that: save the payment details in the database. That’s what you need to implement as the user of requirementsascode.
If your systemReaction is “showProducts”, the method probably needs to get data from the database and display them, as described in chapter 2. But again, your code does no state checking!
That’s the job of the UseCaseModelRunner.
The code using the library just needs to make sure that the conditions are defined correctly, at the beginning of the flows. The conditions are defined as predicates, basically boolean functions.
But the checking of the predicates, i.e. calling these boolean functions in the right state, when the right event occurs, is done by the UseCaseModelRunner.
Uff.. One last thing
If all of this is similar to state machines anyway, why doesn’t it look like it? Because over the years, I noticed that only a minority of stakeholders can understand their „formality“. In contrast, I found that most business stakeholders for example understand Use Case Narratives.
As I want to extract the truth about how the code works, and present it to all kinds of stakeholders, it made more sense to me.
Hope this helps. Otherwise, feel free to ask questions or contact me directly. And please have a look at the helloworld examples of requirementsascode or even better run them, if you are interested. I hope they help with understanding.