Documento di architettura software di riferimento estendibile: buona idea o no?

2

Mi è stato assegnato il compito di scrivere SAD per i nostri attuali due progetti e ce ne sono molti altri in arrivo, tutti simili anche se in modi diversi, per lo più tecnici (hanno tutti requisiti simili)

Per prima cosa stabiliamo cosa penso sia un SAD: fornire una progettazione software che soddisfi requisiti funzionali e non funzionali con casi d'uso chiave (modello 4 + 1) per convalidare la progettazione e vari punti di vista per i vari stakeholder.

Il motivo principale per cui abbiamo deciso di avere i SAD è perché, dopo aver esaminato questi progetti, ci siamo resi conto che i nostri sviluppatori hanno bisogno di indicazioni su cosa usare, quando e come.

La mia domanda ora è : è consigliabile disporre di un SAD principale o di un SAD di riferimento che descriva i requisiti generali del progetto comuni a tutti i progetti (ad esempio la transazione o la prescrizione di un framework specifico per realizzare IoC / DI) .

Ci sono esempi di questo approccio? Una classica vista modello 4 + 1 non funzionerebbe, perché un SAD di riferimento non includerebbe un caso d'uso o una classe concreti. In quanto tale, un SAD di riferimento non progetterebbe in realtà un sistema specifico, il che è un po 'il motivo per cui SAD esiste in primo luogo.

Quello che sto cercando è descrivere una volta le nostre esigenze comuni (struttura del pacchetto, livelli / livelli, framework da usare), mentre i singoli progetti possono minimizzare il loro fattore copia / incolla facendo riferimento a questo documento comune e fornire solo casi d'uso illustra e convalida il diagramma delle classi e la vista fisica / di distribuzione.

Per dare un'idea di cosa abbiamo a che fare qui, le differenze tra questi progetti sono del seguente ordine di grandezza: principalmente microservizi o piccole applicazioni web (tutte le stesse tecnologie di frontend) con modelli di dominio da nessuno a piccolo, o un database razionale o un archivio di documenti. Alcuni hanno REST, JMS, SOAP o una combinazione che entra e / o esce. Tutti i progetti sono una combinazione di queste cose e sono tutti implementati utilizzando gli stessi framework e approcci.

Preferisco non copiare i SAD della pasta solo per modificare alcuni dettagli. Ho anche pensato di scrivere un DAU per un progetto virtuale o definire i "SAD" del profilo a cui fare riferimento. O qualche altro modo "modulare" di collegare i SAD?

Mi piacerebbe avere alcune informazioni su come gestire molti progetti simili in modo omogeneo in modo che i nostri sviluppatori sappiano cosa fare.

/ edit: più ci penso, più sento che un SAD di riferimento non è in grado di catturare correttamente le esigenze concrete delle applicazioni. Sono troppo specifici per il loro caso d'uso. Forse è meglio passare a più SAD simili dopo tutto e cercare di uscire il più possibile da una guida alla codifica?

    
posta Benny Bottema 31.07.2016 - 22:15
fonte

1 risposta

1

Non c'è niente di sbagliato nello scrivere una sorta di documento di base dove si specifica cosa usare quando. Tuttavia, ti suggerisco di non chiamarlo SAD. Inoltre, non è davvero una linea guida per la codifica. Invece chiamala una guida alle migliori pratiche. Hanno anche uno standard di codifica sul posto. Questo copre ciò che stai cercando di mettere lì e impedisce discussioni confuse su SAD principale e riferimento SAD. Quindi per ogni applicazione dovresti scrivere ancora un SAD, che fa riferimento alla Best Practices Guide e allo standard di codifica.

Come nota a margine, potresti incontrare alcune feroci discussioni sulla Best Practices Guide e sullo standard di codifica, a seconda della cultura all'interno della tua organizzazione.

    
risposta data 10.08.2016 - 11:50
fonte

Leggi altre domande sui tag