Orientamento all'architettura (struttura) e struttura del progetto orientata alle caratteristiche

14

Il progetto, ho coinvolto, ha una struttura di file / cartelle di un progetto orientato all'architettura:

Root
|____ Node1
    |____ Event Handlers
    |         |___ <all event handlers of project>
    |____ Events
    |         |___ <all events of project>
    |____ Request Handlers  
    |         |___ <all request handlers of project>
    |____ Requests
    |         |___ <all requests of project>
    |____ ...

È chiaro dal punto di vista architettonico del sistema (è stato proposto dal team di sviluppo).

È una struttura orientata alle funzionalità proposta dal team di designer:

Root
|____ Feature #1
    |____ Event Handlers
    |         |___ <all event handlers of Feature #1>
    |____ Events
    |         |___ <all events of Feature #1>
    |____ Request Handlers  
    |         |___ <all request handlers of Feature #1>
    |____ Requests
    |         |___ <all requests of Feature #1>
    |____ ...

Questa variante è più vicina ai progettisti e descrive chiaramente una caratteristica da implementare.

Le nostre squadre hanno iniziato una guerra santa: qual è l'approccio migliore. Qualcuno potrebbe aiutarci e spiegare i pro ei contro del primo e del secondo. Forse ce n'è un terzo che è più utile e benefico per entrambi.

Grazie.

project-structure

— zzz
fonte

Non capisco nessuna delle due strutture: qual è la differenza tra Eventi e Richieste (e quindi Gestori di eventi e Gestori di richieste)?

— Peter Boughton,

1

Domanda molto chiara - e anche neutrale!

— Michael K,

1

Dal punto di vista della scalabilità, il secondo approccio dovrebbe essere abbastanza facile da ridimensionare orizzontalmente.

— CodeART

11

Vorrei votare per il secondo. Nella prima struttura, i gestori di eventi per non FeatureAsono completamente correlati ai gestori di eventi per FeatureB. Sembra che gli sviluppatori lavoreranno su una funzionalità alla volta e, se stai lavorando su una FeatureXrichiesta, è molto più probabile che dovrai modificare un FeatureXgestore di richieste rispetto, per esempio, a una FeatureZrichiesta.

A proposito, adoro il modo in cui hai posto questa domanda da un punto di vista neutrale.

— Nota per se stessi: pensa a un nome
fonte

1

+1 con un avvertimento: per i piccoli progetti, il secondo si tradurrà in una struttura di file più ampia rispetto a quella dei file in cui inserirli. Utilizzerei il primo per quelli.

— Michael K,

@Michael sono d'accordo, ma in questo caso è un grande progetto.

— Zzz,

1

+1: E se dovessi mai conversare con un utente / cliente, la terminologia può essere abbastanza coerente.

— Steven Evers,

4

Sono sempre stato più a mio agio con il secondo approccio, ma ho sempre una "caratteristica" chiamata generale o comune per le classi veramente condivise / di base.

L'approccio due mantiene le cose veramente separate, ma senza l'area "comune" a volte separa le cose in aree che non si adattano bene.

— Conto
fonte

+1 per comune e generale (ogni progetto ha utilità generali, strumenti ...)

— Zzz,

3

Perché gli inventori delle funzionalità si preoccupano dei dettagli di implementazione? Se questa è la separazione tra le parti dell'argomento, allora penso che la risposta sia chiara. Le persone che inventano idee / funzionalità non determinano la struttura dei file necessaria per gli implementatori.

Questo è un problema particolarmente importante quando l'implementazione di una funzionalità si estende su più dll, ex, database o altri software.

— John Fisher
fonte

1

Ci ho pensato, ma, a parità di altre condizioni, il secondo approccio ha alcuni chiari vantaggi filosofici per tutti tranne che per le applicazioni più banali. Per lo meno, è un buon suggerimento.

— Robert Harvey,

@Robert Harvey: se stai parlando dell'organizzazione idealogica del progetto, allora dovrei pensare a una nuova risposta. Tuttavia, sembra che stiano parlando di file contenenti codice ...

— John Fisher,

La chiave è la separazione delle funzioni in benne distinte. Per tutte le applicazioni tranne le più piccole, avrai bisogno di un tipo di organizzazione come questa, sia che ti riferisca a una struttura di cartelle, una struttura di classe o una convenzione dello spazio dei nomi.

— Robert Harvey,

1

@Robert Harvey: Che dire dei problemi di compilazione e distribuzione? Che ne dici di cose più semplici come semplicemente essere in grado di usare un IDE per scrivere ed eseguire il debug del codice? Alcune di queste cose dovrebbero avere un forte impatto sulle strutture delle cartelle.

— John Fisher,

1

Devo concordare con il secondo approccio, date le due opzioni. Il primo sembra solo una macchia amorfa. Almeno il secondo ha una forma.

Dipende davvero da quanto è grande il progetto. Se le "caratteristiche" sono grandi, ognuna ha bisogno di un proprio bucket distinto.

— Robert Harvey
fonte

1

Non capisco la terminologia che stai usando, ma cercherò di rispondere comunque, poiché entrambe le strutture sembrano essere l'approccio sbagliato.

A meno che tu non abbia solo una manciata di funzionalità, devi raggrupparle in categorie - e ciò non sembra essere soddisfatto in nessuno dei due progetti (a meno che non sia quello che Node1 è inteso come, ma la "tutte le X del progetto" suggerisce altrimenti, e mi chiedo WTF: è un nodo2?)

Potrei considerare qualcosa del genere:

Root
|____ Event Handlers
|   |____ Category A
|   |    |___ Feature #1 EHs
|   |    |___ Feature #2 EHs
|   |    |___ Feature #3 EHs
|   |
|   |____ Category B
|   |    |___ Feature #4 EHs
|   |    |___ Feature #5 EHs
|   |
|
|____ Events
|   |____ Category A
|   |    |___ Feature #1 Events
|   |    |___ Feature #2 Events
|   |    |___ Feature #3 Events
|   |
|   |____ Category B
|   |    |___ Feature #4 Events
|   |    |___ Feature #5 Events
|   |
|

O questo:

Root
|____ Category A
|   |____ Event Handlers
|   |    |___ Feature #1 EHs
|   |    |___ Feature #2 EHs
|   |    |___ Feature #3 EHs
|   |
|   |____ Events
|        |___ Feature #1 Events
|        |___ Feature #2 Events
|        |___ Feature #3 Events
|   
|____ Category B
|   |____ Event Handlers
|   |    |___ Feature #4 EHs
|   |    |___ Feature #5 EHs
|   |
|   |____ Events
|        |___ Feature #4 Events
|        |___ Feature #5 Events

Ma entrambi fanno ipotesi che potrebbero essere completamente fuori luogo - se riesci ad aggiornare la tua domanda con maggiori dettagli, potrei cambiare idea. :)

— Peter Boughton
fonte