Che cosa significa architettura del progetto

Se chiedevano l'architettura di qualche codice o file, potrebbero chiedere quali classi ci sono e come interagiscono. Tuttavia, in un progetto, raggruppiamo le classi in componenti più grandi e questi componenti interagiscono.

Dato che stanno chiedendo del progetto, chiedono il quadro generale dei componenti di alto livello e delle loro interazioni. La costruzione modulare significa che raggruppiamo vari tipi di cose in unità più grandi e più modulari. Le cose nello stesso pacchetto godono di una certa libertà di accesso agli altri interni. Le cose tra i pacchetti usano una sorta di messaggio astratto per comunicare tra di loro, ed è significativo quando / come questi messaggi si verificano. È significativo per l'architettura ciò che è persistente rispetto a ciò che è calcolato e quale componente persiste quale (tipo di) informazione; così come le query di cui è capace un componente e i comandi che può eseguire.

Se stai usando una metodologia di progettazione potresti avere già alcune di queste classificazioni. In caso contrario, puoi descriverli più ad-hoc.

A un livello, spieghi i componenti concettuali, le loro capacità individuali e il modo in cui interagiscono tra loro (cosa scatena l'interazione, quali sono i contenuti delle interazioni, come un componente è responsabile della gestione e della persistenza di certi oggetti mentre un altro componente è responsabile per alcuni altri) e come collegati insieme, questi componenti formano un progetto o un sistema.

Ad esempio, se esiste un collegamento in rete (ad es. server client o server-server), questi dovrebbero essere definiti come interazioni tra componenti identificabili; questo può costituire la base di una delle più ampie viste dei componenti e delle loro interazioni.

Andando più a fondo, possiamo anche aggiungere dettagli alle immagini di persistenza, funzionalità dei componenti e collegamenti tra i componenti e, possiamo spiegare le prestazioni / ridimensionamento (ad es. bilanciamento del carico, modelli di threading, ecc.), e capacità di manutenzione / failover, che aggiungono molta più complessità al quadro concettuale.

Più grande / più ampio, il progetto esiste nel contesto di un dominio (aziendale). Il dominio aziendale è una visione delle entità aziendali e delle loro interazioni (clienti, fornitori, autorità di regolamentazione e altre parti interessate, quali inserzionisti, merchandiser, ecc.). L'architettura del progetto dovrebbe soddisfare i requisiti operativi del sottoinsieme previsto del dominio aziendale, il che significa che dovrebbe indirizzare i ruoli rilevanti e le loro responsabilità nel dominio attraverso le capacità dei componenti (software) interagenti.

Probabilmente ti chiede di descrivere la tua strategia al momento di concettualizzare il progetto. Una panoramica della soluzione.

Ad esempio:

Che tipo di software stai proponendo? Server-client? Desktop? Movile? E perché?

Quali requisiti stai incontrando con la tua scelta?

Ciò introdurrà la tua architettura ad alto livello.

Una volta che l'architettura è stata introdotta, è ora di approfondire i dettagli in modo progressivo. Fai menzione dei modelli di design coinvolti (se ce ne sono). E ancora ... Perché hai seguito tali schemi?

Quali requisiti ti aspetti di incontrare?

Se i tuoi progetti sono formati da due o più applicazioni, è il momento di spiegare cosa fa ognuno di loro. Le loro responsabilità all'interno della soluzione globale. Come si interagiscono tra loro (protocolli, ad esempio: Http, FTP, sftp, ssh, socket, websocket, ...). Se ci sono comunicazioni, è tempo di dire che tipo di comunicazione sta per accadere (quali richiedono e quali sono le risposte). Se c'è qualche tipo di messaggistica è anche il momento di menzionare i formati dei dati: XML, json, CSV, ...

Per qualsiasi scelta, c'è una domanda perché rispondere. La risposta spiegherà quali requisiti stai cercando di soddisfare. I vantaggi rispetto alle alternative scartate.

Infine potresti andare un po 'oltre e spiegare come pensi di portare avanti la soluzione . Ad esempio citando le tecnologie: programmazione di lingue, framework, server, ... Ogni tecnologia verrà utilizzata per una buona ragione, quindi, spiegala.

Non penso che la domanda ti chieda dettagli di basso livello (classi, file, configurazioni). Questi sono comunemente richiesti nei disegni tecnici.

Se si tratta di un riepilogo di architettura di alto livello, elencherei lo stack tecnologico.

"ASP.NET MVC, SignalR, and SQL Server".

..

"Node.JS, RabbitMQ, MySQL"

..

"It's an enterprise bus based solution using Azure Service Bus and REST services that interact with a Cassandra database."

Generalmente, data una panoramica delle tecnologie e dei modelli principali. Diagramalo, forse.

Se vogliono dettagli, si applicano le altre risposte. Invio questa risposta perché, a mio parere, le altre risposte suggeriscono, a mio avviso, un troppo dettaglio per ciò che la domanda sembra essere. Se fossi un cliente e ho chiesto a qualcuno di costruirmi un Widget, e non sapevo con cosa lo avrebbero costruito, potrei chiedere: "Per favore, potresti parlarmi dell'architettura?", A cui vorrei si aspettano un riassunto di base dei blocchi costitutivi di cosa sia il Widget e quali modelli di applicazione di alto livello sono stati utilizzati per correlarli.