Ho sperimentato architetture stratificate basate sul caso d'uso come descritto in Post del blog di Uncle Bob's Clean Architecture . La maggior parte degli esempi che ho visto sono semplici casi di utilizzo "aggiorna il record del cliente", il che ha senso. Dove mi sento un po 'perso è quando si tratta di creare oggetti.
Per rendere le cose un po 'più concrete, supponiamo di avere due casi d'uso (che modelliamo come interlocutori):
begin_operation
end_operation
Ora, la maggior parte delle cose che le operazioni farebbero sarebbero interazioni in questo progetto (piuttosto che i metodi degli oggetti operativi), ma le operazioni rimangono oggetti di prima classe a loro volta. Ad esempio, le operazioni potrebbero dover trasportare bit di stato come un identificatore univoco globale, un file di registro o un elenco di osservatori. Pertanto, sembra che l'interactor begin_operation debba creare una sorta di entità operativa e l'agente end_operation dovrebbe eliminarlo.
La domanda è quindi, come gestiamo la creazione di questi oggetti? Come comunichiamo le informazioni su di loro ai clienti interactor?
Ho pensato ad un paio di possibili approcci:
- Basta creare un nuovo oggetto operazione e passarci sopra un puntatore (possibilmente in una sorta di modulo offuscato).
- Archivia le operazioni in un repository di operazioni di qualche tipo e passa una chiave di ricerca. Questo non è completamente diverso da (1), ma almeno potrei rilevare quando vengo passato un handle di operazione non valido.
Nessun approccio mi sembra perfetto. Qual è il modo migliore per gestirlo?