Quando si scrive un documento di architettura software, dovremmo presentare la tecnologia utilizzata e come si collega alle qualità del sistema che vogliamo ottenere? Ad esempio, abbiamo scelto .NET perché arg1, arg2 ..
La mia sensazione è NO, l'architettura dovrebbe essere stabile nei cambiamenti; ma la realizzazione concreta di alcuni moduli può cambiare rispetto alla tecnologia utilizzata.
Direi che dipende da quale livello descrive il documento:
Se non stai elencando le tecnologie, allora stai solo elencando i concetti.
I concetti - senza un'applicazione concreta e tecnologie specifiche - non sono davvero molto interessanti.
Chiunque può elencare una serie di concetti e pretendere che tutti lavorino insieme in un modo magico.
architecture should be stable in change
Non riesco a vedere quale sia il punto. Se hai intenzione di elencare concetti, essi mai cambiano. Ma non dice a nessuno cosa comprare, quali contratti firmare o cosa programmare da fare.
some modules can change in respect to the technology used
Se sì, dove documenterai le scelte tecnologiche? Ecco a cosa serve il documento di architettura.
Indica a tutti cosa usare.
Un'architettura dovrebbe presentare la tecnologia utilizzata, ma solo per API pubblica e qualsiasi risorsa condivisa .
Se sto cercando di capire come il sistema di inventario parlerà con il sistema degli ordini di lavoro, allora ho bisogno di sapere quali sono le mie opzioni.
Non mi interessa davvero se il sistema è sviluppato con C # o Java, a meno che non influenzi la licenza o l'assunzione; Mi interessa se sta usando SOAP, REST o qualche tipo di EDI. Mi interessa anche quale versione e quali protocolli sono in uso. Questi devono essere inseriti in un documento di architettura, altrimenti non mi dice nulla sull'architettura attuale.
Mi interessa anche del database - questa è una risorsa condivisa. Se mi sto appoggiando verso ETL come soluzione, allora fa una grande differenza se l'origine è Oracle o SQL Server.
Oh, e ho bisogno di sapere delle dipendenze. Ad esempio, se hai deciso di utilizzare NServiceBus per il tuo ESB, ho bisogno di saperlo perché richiede una diffusione diffusa di MSMQ e, in quanto architetto, dovrei essere in grado di dire qualcosa su quanto affidabile e / o scalabile sia è. Allo stesso modo, se hai deciso di utilizzare WCF con l'autenticazione del certificato reciproco, faremmo meglio a prepararci a implementare una PKI.
D'altra parte, non mi importa se hai scelto Spring o Castle per l'iniezione della tua dipendenza, o se stai usando Linq su SQL o Entity Framework nella tua app .NET. Per favore non annoiare i tuoi lettori con un account insopportabile dei meriti di log4net rispetto a NLog.
Non c'è una semplice risposta "sì" o "no": equivale a chiedere quanti dettagli tecnici dovresti entrare durante un incontro con i tuoi clienti. La risposta è "solo quanto necessario". Sei l'architetto; dovresti capire abbastanza dell'architettura per essere in grado di determinare se alcuni dettagli di implementazione hanno un impatto più ampio sull'intero sistema o azienda.
Qualunque sia la tua visione, vuoi mostrare come le qualità desiderate vengono promosse dalle tue scelte. Se non ritieni che i dettagli specifici ti aiutino a descrivere quella vista, non includerli.
Ciò che documentate dipenderà molto dalla vista e dal contesto in cui vengono prese le decisioni tecnologiche. Alcune decisioni tecnologiche, come framework, piattaforme o linguaggio, sono un grosso problema: avranno un impatto significativo sull'architettura del sistema. Considera il pubblico e come intendi utilizzare la descrizione dell'architettura.
Nella mia esperienza è utile sapere quali sono le decisioni tecnologiche e da dove provengono. Ad esempio, la tecnologia era una limitazione del cliente o una decisione del team? Oltre a questo ho trovato sufficiente ricordare brevemente ciò che fornisce una tecnologia, specialmente se è qualcosa fuori dal comune per la tua squadra o se è fondamentale per ottenere una qualità specifica.
Leggi altre domande sui tag architecture documentation