A question of "state"

At the lowest level you have things like a car ignition switch which has a well defined and temporally unambiguous state.

As programmers we are very comfortable at this level - variables and database records are typically dealt with at this level.

At the next level a service has a state comprising many different properties, some of which are exposed (like speed and turn signals) and others internal (like the gear and revs).

Object oriented programming allows us to deal with this by wrapping these different states as a class or in a service boundary. Within this we enforce a single state consistency model.

At a system level the notion of a single coherent and temporally unambiguous state starts to break down.

We need to look at reactive systems and rule based "swarm" behaviours.

One way we deal with this is to reduce the level of state that we consider at each level and we allow/force each lower level to encapsulate and enforce its own state consistency boundaries. This does mean at the system level we have to be comfortable with some fuzziness.

Intuitively, and in physical systems, we already know and do this - that is why the concept is so obvious in the ignition switch->car->traffic example.

In IT (and especially in monolithic applications) we are not so good at this.

What this means is that if any decision requires the current state of an entity as part of that process then the decision can only be taken by the entity itself.