L'architettura di un sistema descrive le decisioni e valori di design di alto livello che guidano lo sviluppo di quel sistema. Esistono un paio di schemi a livello di architettura che evitano problemi specifici, ma non esiste un'architettura "corretta" o "migliore". Inoltre, non esiste una singola architettura per ogni sistema. L'architettura può descrivere come interagiscono i componenti di un sistema, come viene distribuito il sistema, come viene mantenuta la sicurezza, come vengono scelte le tecnologie, ....
Poiché l'architettura riguarda le decisioni , non è generalmente possibile decodificare queste decisioni. Potresti notare alcuni modelli di architettura (ad esempio un'architettura di microservizio o un'architettura MVVM), ma ciò non equivale a capire perché questa architettura è stata scelta per quel dominio problematico.
Se un'architettura è adatta dipende molto dallo scopo e dal contesto di quel sistema. Per esempio. progettare un sistema attorno a un bus di messaggi centrale può avere molto senso per integrare le origini dati aziendali, ma probabilmente è un'architettura inutile per un'applicazione di fogli elettronici come MS Excel. Non penso sia sensato esprimere questo contesto necessario come parte di qualche "metrica". Invece, dobbiamo chiederci:
Data questa architettura per questo problema:
- In che modo l'architettura aiuta a risolvere questo problema?
- In che modo rende più difficile una soluzione?
Sfortunatamente, ciò richiede esperienza . Fino a quando non avrai sperimentato diversi difetti di un'architettura, probabilmente non penseresti a questi problemi. Quelli sono sconosciuti sconosciuti . Ma una volta che sappiamo come non risolvere questo problema, possiamo valutare un'architettura e dire: "Nella mia esperienza, questa architettura ha difficoltà con $ feature", dove la caratteristica in questione può essere una qualità come scalabilità, manutenibilità, affidabilità, separazione di preoccupazioni o qualsiasi altra cosa.