Quando è necessario il layer Use Case?

5

Nel suo post sul blog The Clean Architecture Zio Bob suggerisce un'architettura a 4 livelli. Comprendo la separazione tra regole di business, interfacce e infrastruttura, ma mi chiedo se / quando sia necessario disporre di livelli separati per oggetti dominio e casi d'uso. Quale valore aggiunto porterà, rispetto al fatto di avere i casi d'uso come "servizi di dominio" nel livello dominio?

Le uniche informazioni utili che ho trovato sul Web riguardo a un caso di utilizzo sono un articolo di Martin Fowler, che sembra contraddice lo zio Bob sulla sua necessità:

At some point I may run into the problems, and then I'll make a Use Case Controller - but only then. And even when I do that I rarely consider the Use Case Controllers to occupy a separate layer in the system architecture.

Modifica:

Mi sono imbattuto in un video di Architettura: The Lost Years di Uncle Bob keynote, in cui spiega in modo approfondito questa architettura. Molto informativo.

    
posta Meta-Knight 27.09.2012 - 19:09
fonte

2 risposte

5

Non sono d'accordo con l'uso del termine "use case" da parte dello zio Bob, ma capisco cosa sta facendo. In ogni caso, non voglio proprio cavillare sulla semantica del termine.

Per motivi di questa domanda, use cases è application specific business rules.

La tua domanda è davvero "quando sono necessari livelli separati per le regole aziendali e le regole aziendali specifiche dell'applicazione?" E la risposta rapida è che ne hai bisogno quando la tua applicazione diventa abbastanza grande da giustificarlo.

Se ci sono un piccolo numero di regole da entrambi i set, allora è altrettanto semplice mantenere l'implementazione di quelle regole all'interno di un singolo livello di applicazione. Se ci sono molte regole per entrambi i set, allora vorrai suddividerli su livelli specifici.

Lo zio Bob stabilisce una regola secondo cui i cerchi interni non dovrebbero conoscere i cerchi esterni nel suo diagramma architettonico. E questa è in definitiva la risposta alla tua domanda. Man mano che le regole evolvono e hanno una chiara definizione dagli altri, dovrai isolarli per separare i livelli.

    
risposta data 27.09.2012 - 19:51
fonte
0

Non sono un esperto in materia, ma questo è il modo in cui lo capisco. L'idea con un livello separato per gli oggetti dominio e gli oggetti caso d'uso è che potrebbe essere necessario implementare più versioni del livello dell'oggetto caso d'uso per applicazioni che dovrebbero avere un comportamento diverso, ma seguire le stesse regole aziendali. Il modo in cui lo spiega è il livello più interno è le regole aziendali e il livello del caso utente è le regole di comportamento dell'applicazione.

Sia che tu sia d'accordo con lo zio Bob o no, a mio parere la risposta fornita da @ GlenH7 non è nello spirito di ciò che lo zio Bob sta promuovendo. Non vuole che tu aspetti finché la tua applicazione non diventa più grande prima di separare i livelli. Vuole che l'iterazione zero sia quando progettate come manterrete i livelli architettonici separati e disaccoppiati. L'idea è che una volta che si presenta la necessità di sostituire uno strato, dovresti essere in grado di agire su quella necessità in modo rapido e semplice perché hai già separato gli strati prima della mano. Se aspetti che l'applicazione si ingrandisca o che si presenti la necessità di separare i livelli, probabilmente non lo farai perché è troppo lavoro. Ma se lo fai facilmente lo farai solo perché sei curioso di vedere cosa succederebbe se scambiassi un livello con uno alternativo.

    
risposta data 16.08.2017 - 18:10
fonte

Leggi altre domande sui tag