Al lavoro, stiamo creando un'app per Android. Abbiamo un modulo di business logic per parlare con un'API per le operazioni CRUD. L'app su cui sto lavorando, il modulo UI, parla al modulo di business logic per creare, aggiornare, eliminare e ottenere entità. Queste entità possono trovarsi in diversi stati (non avviati, in attesa, avviati, terminati come pochi altri). Il problema è che alcune di queste entità provengono da fonti diverse, alcune delle fonti sono prive di stato (e quindi è necessario gestirne manualmente lo stato) e alcune sono piene (per queste ci si fida dello stato delle fonti). Il modulo di business logic deve consolidare le fonti in un modello unificato per il modulo UI (poiché non vogliamo che il modulo UI sia interessato ai dettagli nitidi delle fonti di entità).
Sto lavorando al componente dell'interfaccia utente e c'è stata una discussione con gli sviluppatori che hanno lavorato al modulo di business logic su come lo stato dovrebbe essere gestito. Stavamo parlando di se il livello dell'interfaccia utente dovesse gestire lo stato degli oggetti del dominio o se il modulo della business logic dovesse gestirlo. Ho sostenuto che il modulo di business logic dovrebbe mantenere un FSM per ogni entità, in modo tale che il livello di interfaccia utente possa impartire un comando al livello di business logic per una data entità, e tale comando verrà eseguito se è valido per lo stato attuale delle entità. Se il comando era valido, l'FSM passerebbe a un nuovo stato, eseguendo effetti collaterali come le chiamate API se necessario.
Essendo l'idea generale, il livello dell'interfaccia utente non dovrebbe essere in grado di mettere gli enti aziendali in stati non validi, questo sarebbe applicato da un FSM sottostante e gli effetti collaterali potrebbero essere mantenuti in un unico posto: la tabella di transizione dello stato. Ciò ha anche il vantaggio di poter riutilizzare il modello di business logic per moduli UI completamente diversi (con UX / flussi completamente diversi) e garantire che la logica aziendale si comporti come previsto su più applicazioni client.
Questo suggerimento non ha funzionato, e invece siamo atterrati su una soluzione proposta che prevede in parte la gestione di ogni stato di entità nel livello dell'interfaccia utente e parzialmente nel livello della logica di business, che mi riguarda. Ad esempio, il livello dell'interfaccia utente interrogherà il livello della logica aziendale per le entità e potrebbe essere necessario decidere lo stato iniziale di un'entità, a seconda dello stato corrente delle entità. Ma lo strato UI dovrebbe farlo solo se lo stato attuale delle entità è x o y, non a, b o c. Oltre a ciò, l'idea reale di utilizzare un FSM per gestire lo stato sembrava essere un no-flyer (forse non mi sono spiegato abbastanza bene in quanto l'incontro è stato chiamato a breve termine).
Da quanto ho detto qui, un FSM sembra una soluzione ragionevole, e sono sulla strada giusta nel pensare che dividere la gestione dello stato attraverso la logica di business e i livelli dell'interfaccia utente sia una cattiva idea?
Sono consapevole che la domanda è piuttosto vaga, ma non sono autorizzato a discutere le specifiche del progetto al di fuori dell'azienda. Potrei creare un esempio forzato che rifletta le entità, gli stati e le transizioni del dominio se fosse di aiuto.
EDIT:
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.