Racconto breve: cosa deve fare un architetto?

Questo articolo è un racconto breve che imita le domande e risposte, e l'autore utilizza uno stile umoristico per analizzare brevemente il lavoro degli architetti: Voglio diventare un architetto software.

Questa è un'ottima opzione per i giovani sviluppatori software.

Voglio guidare il team e prendere decisioni importanti su database e framework, webserver, ecc.

Ah, allora non vuoi fare affatto l'architetto software.

Ovviamente volevo essere io a prendere decisioni importanti.

Va bene, ma non includi nella tua lista decisioni importanti, che sono decisioni irrilevanti.

Che vuoi dire? Stai dicendo che i database non sono decisioni importanti, sai quanto spendiamo per essi?

Forse costa troppo. Tuttavia, i database non sono una delle decisioni più importanti.

Come puoi dire una cosa del genere? Il database è il nucleo del sistema, dove tutti i dati sono sistematizzati, classificati, indicizzati e accessibili. Senza un database, non ci sarebbe un sistema.

Il database è solo un dispositivo IO che fornisce alcuni strumenti utili per classificazione, interrogazione e reportistica delle informazioni, ma queste sono solo funzioni ausiliarie dell'architettura di sistema.

Aiuto? È scandaloso.

Esatto, è ausiliario. Le regole di business del sistema possono essere in grado di sfruttare alcuni di questi strumenti, ma questi strumenti non sono intrinseci alle corrispondenti regole di business. Se necessario, puoi sostituire quelli esistenti con altri strumenti; E le regole aziendali non cambieranno.

Beh, sì, ma doveva essere riprogrammato, perché questi strumenti erano usati nel database originale.

Questo è il tuo problema.

Che vuoi dire?

Il tuo problema è che pensi che le regole di business dipendano dagli strumenti di database, ma non è così. O almeno, non dovrebbe essere così finché non viene fornita una buona architettura.

È semplicemente pazzesco. Come si creano regole di business che non utilizzano quegli strumenti?

Non sto dicendo che non usino strumenti di database, ma non dipendono da esso. Le regole di business non devono sapere quale database stai usando.

Quindi, come si ottengono le regole di business senza sapere quali strumenti usare?

Inverti le dipendenze in modo che il database dipenda dalle regole aziendali. Assicurati che le regole di business non dipendono dal database.

Stai dicendo sciocchezze.

Al contrario, sto usando il linguaggio dell'architettura software. Questo è il principio dell'inversione della dipendenza: gli standard di basso livello dovrebbero basarsi su standard di alto livello.

Sciocchezze! Criteri di alto livello (supponendo che si riferiscano a regole di business) Chiamata di criteri di basso livello (assumendo riferimento a database). Pertanto, il criterio di alto livello si basa su quello di basso livello secondo il principio che il chiamante dipende dal destinatario. Lo sanno tutti!

Questo vale anche in tempo reale. Ma quando si compila, ciò che vogliamo è l'inversione delle dipendenze. Il codice sorgente delle linee guida di alto livello non dovrebbe menzionare il codice sorgente delle linee guida di basso livello.

Dai! Come puoi fare una chiamata senza menzionarla?

Certo nessun problema. Questo è ciò che comporta l'orientamento agli oggetti.

L'orientamento agli oggetti riguarda la creazione di modelli nel mondo reale, combinando dati, funzionalità e oggetti coesivi. Si tratta di organizzare il codice in una struttura intuitiva.

È quello che dicono?

Come tutti sappiamo, questa è la verità ovvia.

Sì, lo è, tuttavia, quando si usano linee guida orientate agli oggetti, è effettivamente possibile invocarlo senza menzionarlo.

Beh, come si fa?

Nella progettazione orientata agli oggetti, gli oggetti inviano messaggi tra loro.

Esatto, ovviamente.

Quando un mittente invia un messaggio, non conosce il tipo di destinatario.

Dipende dal linguaggio usato. In Java, il mittente conosce almeno il tipo base del ricevitore. In Ruby, il mittente almeno sa che il destinatario è in grado di gestire i messaggi ricevuti.

Giusto. In ogni caso, però, il mittente non conosce il tipo specifico di ricevitore.

Esatto, beh, lo è.

Pertanto, un mittente può progettare un ricevitore per svolgere una funzione senza menzionare il tipo specifico di ricevitore.

Esatto, esatto. Capisco. Tuttavia, il trasmittente dipende ancora dal destinatario.

Questo vale anche in tempo reale. Tuttavia, è diverso quando viene compilato. Il codice sorgente del mittente non menziona né dipende dal codice sorgente del destinatario. In effetti, il codice sorgente del destinatario dipende dal codice sorgente del mittente.

Assolutamente no! Il mittente dipende comunque dalla classe che invia.

Forse da qualche codice sorgente sarà più chiaro. Il paragrafo seguente è scritto in Java. Per prima cosa c'è il mittente:

Ecco il ricevitore:

Nota: Il destinatario dipende dal mittente, SpecificReceiver dipende dal mittente e non ci sono informazioni correlate al destinatario nel mittente.

Sì, ma stai mentendo, hai messo l'interfaccia del destinatario nella classe mittente.

Stai iniziando a capire.

Che ne sai?

Naturalmente, è il principio dell'architettura. Il mittente ha l'interfaccia che il ricevitore deve implementare.

Se questo significa dover usare classi annidate, allora ......

Le classi annidate sono solo uno dei mezzi per raggiungere un fine, ci sono altri modi.

Aspetta un attimo. Cosa c'entra questo con i database? Abbiamo iniziato a parlare di database.

Diamo un'occhiata un po' più al codice. La prima è una semplice regola aziendale:

Le regole di business non hanno molto peso.

Questo è solo un esempio. Potrebbero esserci altre classi simili che implementano molte regole di business diverse.

Ok, quindi cos'è esattamente Gateway?

Fornisce tutti i metodi di accesso ai dati tramite regole aziendali. Implementalo come segue:

Nota: Questo è nelle regole aziendali.

Ok, cos'è la classe Qualcosa?

Rappresenta un semplice oggetto di business. Lo metto in entità.

In definitiva, l'implementazione di BusinessRuleGateway è questa classe che conosce il vero database:

Inoltre, si noti che le regole di business chiamano il database a runtime; Tuttavia, al momento della compilazione, il database coinvolge e dipende da businessRules.

Beh, credo di aver capito. Stai solo usando il polimorfismo per nascondere il fatto che il database è implementato dalle regole di business. Tuttavia, è ancora necessaria un'interfaccia per fornire tutti gli strumenti del database alle regole di business.

No, affatto. Non abbiamo tentato di fornire strumenti di database alle regole aziendali. Invece, usano regole di business per creare interfacce per ciò di cui hanno bisogno. Implementare queste interfacce ti permette di chiamare gli strumenti giusti.

Sì, ma se devi usare ogni strumento per tutte le regole di business, allora basta mettere lo strumento nell'interfaccia gateway.

Ah, non credo che tu abbia ancora capito.

Capire cosa? Questo è già chiaro.

Ogni business rule definisce una sola interfaccia per gli strumenti di accesso ai dati di cui ha bisogno.

Aspetta un attimo, che ne dici?

Questo è il Principio di Segregazione delle Interfacce. Ogni classe di regole aziendali utilizza solo alcune funzionalità del database. Pertanto, le interfacce fornite da ogni business rule possono accedere solo alle relative funzionalità.

Tuttavia, ciò significa che esistono molte interfacce e molte piccole classi di implementazione che chiamano altre classi di database.

Ottimo, stai iniziando a capire.

Ma è troppo disordinato e una perdita di tempo. Perché farlo?

Questo è organizzato e fa risparmiare tempo.

Dai, raccogli molto codice solo per il gusto di scrivere.

Al contrario, decisioni irrilevanti possono essere ritardate da decisioni architettoniche importanti.

Cosa significa?

Ricordo che all'inizio dicevi di voler diventare un architetto software, vero? Vuoi prendere tutte le decisioni che contano davvero.

Sì, è quello che pensavo.

Vuoi prendere decisioni su database, server web e framework, giusto?

Sì, dici che nulla di tutto ciò conta. Solo contenuti irrilevanti.

Giusto. Questo è tutto. Le decisioni importanti prese dagli architetti software sono quelle che ti permettono di prendere decisioni su database, server web e framework.

Ma devi prima decidere quali!

No, non funziona. In effetti, queste possono essere decise più avanti nel ciclo di sviluppo, quando le informazioni sono più abbondanti.

È un disastro se gli architetti identificano i framework in anticipo solo per scoprire che non forniscono le prestazioni richieste o introducono vincoli intollerabili.

Solo quando l'architetto decide di posticipare la decisione prenderà una decisione quando le informazioni sono sufficienti; I team che non utilizzano dispositivi e framework IO lenti e ad alta pressione di risorse possono creare ambienti di test veloci e leggeri a discrezione degli architetti. Solo i suoi architetti si preoccupano di ciò che conta davvero e ritardano chi non conta nulla, e una squadra del genere è quella fortunata.

Sciocchezze, non capisco affatto cosa intendi.

Beh, dai un'occhiata a questo articolo, altrimenti dovrai aspettare altri 10 anni per capirlo.