At work, we are creating an android app. We have a business logic module for talking to an API for CRUD operations. The app I'm working on, the UI module, speaks to the business logic module to create, update, delete and get entities. These entities can be in various states (not started, awaiting, started, ended as well as a few others). The problem being, some of these entities come from different sources, some of the sources are stateless (and therefore we need to manually manage the state of these) and, some are state full (for these we trust the sources state). The business logic module needs to consolidate the sources into a unified model for the UI module (as we don't want the UI module to be concerned with the nitty gritty details of the entity sources).
I am working on the UI component, and there was a discussion with the developers working on the business logic module about how state should be handled. We were talking about if the UI layer should manage the state of the domain objects or if the business logic module should handle it. I argued that the business logic module should maintain an FSM for each entity, such that the UI layer can issue a command to the business logic layer for a given entity, and that command will be executed if it's valid for the entities current state. If the command was valid, then the FSM would transition to a new state, executing side effect such as API calls if required.
The general idea being, the UI layer should not be able to put business entities into invalid states, this would be enforced by an underlying FSM and side effects could be maintained in a single place - the state transition table. This also has the benefit that we can re-use the business logic model for completely different UI modules (with possibly completely different UX/ flows) and be guaranteed that the business logic behaves as intended across multiple client applications.
This suggestion didn't fly, and instead we've landed on a proposed solution which involves partially managing each entities state in the UI layer and partially in the business logic layer, which concerns me. For instance, the UI layer will query the business logic layer for entities and may possibly need to decide the initial state for an entity, depending on that entities current state. But the UI layer should only do this if the entities current state is x or y, not a, b or c. On top of that, the actual idea of using an FSM to manage the state at all seemed to be a no-flyer (perhaps I didn't explain myself well enough as the meeting was called at short notice).
From what I've said here, does an FSM sound like a reasonable solution, and am I on the right path in thinking that splitting the state management across the business logic and UI layers is a bad idea ?
I'm aware the question is quite vague, but I am not allowed to discuss the specifics of the project outside the company. I could create a contrived example that reflects the domain entities, states and transitions if it would help.
To clarify; the UI layer will maintain it's own FSM to manage it's state (i.e. the user tapped a button, issue a command to the UI FSM, if there is a valid transition, then execute side effects and transition to new state). The UI FSM may issue commands to entity FSM's as side effects of the transitions.