In the C # solution I'm working on, the core of the application logic is implemented as a state machine using (very good) Stateless . There are other parts of the business logic, modeled in a number of other classes, for different areas and functions that the application shows, but this is the one that controls the main changes in the main states of applications.
Although each state transition is pretty simple in itself (event notification, setting eventArgs, listening for other events, ...), and I use substations when applicable, for me it starts to look a little too big. I understand that this is not an exact measure, but if you look and think about substations, you may well find that they can be separate state machines on their own.
Is there an obvious way that I'm missing to create a separate sub-statemachine (so to speak) using Stateless by mapping each state machine to a class
>The first blocking problems that come to my mind (especially the second one):
a state machine with one large part fires events in all state changes: after splitting, each individual state machine fires each trigger. Thus, it would be better if the facade collected all the events and re-launched them for customers in order to hide many state machines (in the end, they are implementation details for customers).
Stand-alone substations take care of bubbling up the status / substation chain, as well as down. So, for example, for a given state Athat has substations, you can define a trigger (in one place, AConfigure) that will force the state machine to leave A, regardless of which substrate Awe are in. How does this work with individual sub-state machines?