Il modello di sistema ha una classe contenitore del flusso di lavoro, le cui istanze possono contenere sottoclassi della classe Node, specializzate per comportamenti diversi (es. Iniziale, Intermedio1, Intermedio2, Finale). Esistono altre classi Le classi di nodi vengono utilizzate come contesto, ad esempio Utente e Contenuto (che possono avere flussi di lavoro di tipi diversi), ma non rappresentano un problema qui.
Tuttavia, ciascuna sottoclasse di nodi ha diverse "aree" di comportamento: metadati di base (come nome e parametri), supporto della logica di transizione dello stato (ad esempio, condizione per la disponibilità del nodo, ecc.), supporto di messaggistica per più lingue e canali (questo è il nucleo del business case), regole per possibili ulteriori azioni per il nodo. (E non ho toccato aspetti più ubiqui come la gestione dei diritti di accesso qui - solo per dire che l'elenco degli aspetti non è scolpito nella pietra.) Per ora, il flusso di lavoro è principalmente una sequenza di nodi, ma ci sono alcune eccezioni nelle transizioni. Quindi il contenitore è modellato come elenco di nodi e i nodi sono indirizzati dai loro id.
La maggior parte dell'approccio diretto, ad esempio, la suddivisione di ogni sottoclasse di nodi in NodeData, NodeTransition, NodeMessaging, NodeAction significa perdere il punto e introduce la necessità di mantenere sincronizzate entità strettamente correlate (ad esempio, NodeMessaging richiede nome da NodeData, possibili azioni da NodeAction, ecc. , ecc., quindi questo tipo di scomposizione sembra innaturale e quindi le entità modellate sono scomode.
L'uso delle classi è principalmente il rendering di visualizzazioni e messaggi per diversi canali, con alcune statistiche sul Contenuto del corrente "Nodo" che usa e, naturalmente, per Flusso di lavoro sta cambiando da un "nodo" a un altro. Forse non ho menzionato alcuni casi minori, ma come vedo, solo Workflow e Nodi sono entità, e altre cose hanno comportamenti molto limitati, quindi forse possono essere modellati come oggetti valore ...
Quale potrebbe essere un buon modello qui? Immagino che le implementazioni dei flussi di lavoro possano avere alcuni buoni schemi per adattarsi alle esigenze del sistema in questione. Sono a conoscenza solo di un'implementazione, che sfrutta pesantemente l'architettura dei componenti, e io è eccessivo per il caso, e inoltre non penso sia abbastanza elegante.
E come menzionato nel titolo, preferisco le soluzioni, che sono più vicine alla progettazione basata sul dominio. Il dominio dell'applicazione non fornisce dettagli sufficienti per nominare anche qualcosa che vada oltre le sottoclassi di nodi, quindi un patter di dominio della soluzione adeguato (in termini di complessità) potrebbe essere utile. In DDD-speak, si tratta di aggregazione giusta.