Avoid state machines

One of the key idea of functional programming, that is being so popular nowadays, is immutability. However, usually this is better understood on low level programming concepts like variables or data collections, but when it goes to an architecture, many programmers are deluded to apply state machines as a de-facto way to go.

Computer science university lections are telling that one of the key concepts behind computing is a Turing state machine (TSM). Hence if state machine lies as a grounding concept for a hardware architecture, it seems to be a good idea to apply the same pattern while making a high-level software architecture. Partly this is true because TSM concept is vital for classical computer science, but modern hardware architecture is based on von Neumann model, not on TSM.

In practise, working with a state for one class of objects is error-prone due to a difficulty to maintain transition logic across different parts of application. Transition states cannot be isolated to one module, because, in most cases, they become a subject for inter-module communications.

For example, if an application has an Order entity with Requested, Paid, Delivered states, it is better to redesign an encompassing Order object to separate Request, Payment, Delivery entities. That redesign should be kept both in database and in code levels, even if writing to a database is located in one module.

That is short words. Hope you have got an idea. The bottom line is: state machine is an anti-pattern for software architecture.