Le tecnologie utilizzate in una parte dell'applicazione dell'architettura o rappresentano dettagli di implementazione / dettagli di progettazione?

In qualità di architetto di software, dovrai prendere decisioni quali componenti / tecnologie sono essenziali per la tua architettura e quali sono i "dettagli di implementazione". Ad esempio

• è una parte specifica del sistema di database dell'architettura di alto livello? Per alcune applicazioni questo può essere vero, per altri è importante mantenere i programmi indipendenti dal fornitore del database. Strumenti come gli ORM possono aiutarti qui, ma poi potresti dover prendere la decisione architettonica di scegliere un ORM specifico.

• sono i linguaggi di programmazione per la parte di sistema dell'architettura di alto livello? Beh, nella maggior parte dei casi non è possibile cambiare facilmente la lingua in seguito, quando hai già scritto diverse migliaia di righe di codice, quindi questa sarà normalmente una decisione architetturale di alto livello. Naturalmente, conosco esempi in cui le librerie sono scritte in un DSL e tradotte automaticamente in diversi linguaggi di programmazione, ma non è il caso tipico.

• l'uso di Spring AMQP deve essere parte della tua architettura o di un dettaglio di implementazione? Bene, AMQP AFAIK è un protocollo standard e esistono diverse implementazioni / librerie che lo supportano. Se vuoi mantenere l'opzione di modificare la libreria AMQP in un secondo momento, probabilmente vuoi che sia dichiarato come dettaglio di implementazione.

In effetti, alcune tecnologie sono più facili da conservare "come dettagli di implementazione" di altre, ed è spesso un compromesso tra una maggiore flessibilità e un maggiore sforzo di sviluppo in cui tracciare la linea.

Dipende - per prima cosa, la definizione di architettura è piuttosto confusa: il SEI fornisce probabilmente più di 100 definizioni del termine , anche se quello che uso più spesso personalmente è quello di Chris Verhoef:

Architecture is that which is hardest to change.

In base a questa definizione, è più semplice caratterizzare l'architettura guardando indietro su un sistema esistente che guardando in avanti mentre il sistema è in fase di progettazione. Può ancora essere utilizzato durante la progettazione, IMO. Potresti dire che una scelta tecnologica può essere considerata architettonica quando hai progettato ampie parti del sistema in modo tale da essere strettamente collegate alla tua tecnologia. (Ad esempio, la scelta del linguaggio di programmazione è estremamente probabile che sia una decisione architettonica.)

Bene, dipende.

Esistono chiaramente tecnologie architettoniche che vanno direttamente in una documentazione di architettura, come CORBA o .NET o MessageQueue.

Se puoi avere una forma astratta di esso, ad es. solo l'interfaccia supportata da più implementazioni, mantenendola a livello astratto. Se ce l'hai, specifica quelli nella documentazione di implementazione. Se non si dispone di una documentazione di implementazione, puoi specificarlo nell'architettura generale.

D'altra parte, ci sono tecnologie che probabilmente non entrano mai in una documentazione di architettura, come un certo parser JSON o simili.

Su sistemi molto complessi, avresti comunque una specifica di sistema, che è più di un'architettura generale.

Quindi, in breve, direi:

Architecure: sistema astratto e livello di componenti concreti Implementazione: componente astratto e livello di modulo concreto

utilizzando definizione di AidanCully

Architecture is that which is hardest to change.

puoi decidere da solo se la tecnologia / libreria è l'architettura o i dettagli dell'implementazione.

Se nascondi la tecnologia / libreria dietro livello di astrazione / facciata , questa astrazione diventa parte dell'architettura e della tecnologia / library è il dettaglio dell'implementazione.

Se si utilizza direttamente la tecnologia / libreria (senza nasconderlo dietro un'astrazione), la tecnologia / libreria è parte dell'architettura.

Esempio: nel contesto di MessageQueing puoi

• usa broker RabbitMQ direttamente (come parte dell'architettura)
• usa l'astrazione spring-amqp (come parte dell'architettura) quindi usare RabbitMQ è un'implementazione dettaglio
• Implementa la propria facciata di messaggi (come parte dell'architettura), quindi utilizzando amqp, operazione asincronica, l'esistenza di una coda sono tutti dettagli di implementazione.

Esempio: in Microsoft.net puoi

• usa il provider di database mssql-ado.net direttamente (come parte dell'architettura)
• oppure puoi usare l'oledb-database-astrazione (come parte dell'architettura) così mssql diventa un dettaglio di implementazione
• oppure puoi utilizzare un repository (come parte dell'architettura) per nascondere l'esistenza di un database come dettaglio di implementazione