I'm putting together some ideas and personal conventions on how to configure state machines when using a language specific library.

Because I'm adding state machines to existing model classes in my project, some of the states I wish to leverage are distributed across their relations. State is not contained in a singular field, but is instead informed by other things going on in the system that I must retrieve.

Is it normal/allowed for a state machine implementation to source data from related model data? Or is it a hard requirement of a state machine implementation that the domain object having its state tracked must provide a single field for the state structure to serialize into?

(This is instead of interpreting the state machine's output and translating it into model operations like inserts, updates and/or deletes.)


A state machine has inputs and outputs along with a state. How you represent that state is up to your implementation.

There is no requirement that a state be kept in a single field. I have often built state machines that were a composite of a number of fields. I would have a state machine design describing the state transitions. To aid in understanding, for instance, by logging the state transitions, I would have a function that reported the state of the implementation by deriving it from the composite value of the fields.

| improve this answer | |
  • Great description, and very much like what I've already done. I produce multiple states and my state machine configuration leverages them. But I actually end up only consuming one state value out of several for writes. – Omega Jun 11 '18 at 13:52

There's no requirement that state be kept in a single field, but it's much easier to test, verify and generally reason about a state machine if it's self-contained.

Leaving state scattered throughout the model is therefore less than ideal - unless it's impractical, keeping the relevant state inside the machine (even if that requires multiple fields there) is preferable.

If you don't see these secondary fields as part of the top-level state, it's possible to

  • handle them either with a nested state machine, or to
  • convey them to the state machine as extra input parameters (so they effectively distinguish a finer-grained event type).

Also, on an entirely unrelated note, you're not really leveraging something unless you have a fulcrum, or some metaphorical kind of mechanical advantage. Without those, you're just using.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.