Secondo me, l'architettura evolutiva si riduce a rendere l'architettura facile da modificare. Ora l'architettura è spesso definita come le cose che dovresti ottenere subito perché saranno difficili da cambiare in seguito.
Come si combina questo? C'è qualche differenza tra l'architettura evolutiva e semplicemente la minimizzazione della quantità di architettura?
La nota chiave di Neal Ford sull'architettura evolutiva può essere trovata qui.
Parafrasando:
Architecture is the decisions that you wish you could get right early in a project, things that people perceive as hard to change. But what if we built architectures that expect change?
An evolutionary architecture supports incremental, guided change as a first principle across multiple dimensions.
Prosegue descrivendo diversi scenari architettonici, a partire da Big Ball of Mud, architetture a strati, microkernel e REST, e culminando in microservizi, che afferma di avere n dimensioni della capacità evolutiva (dove < em> n è il numero di microservizi distinti).
Secondo Ford, architetture evolutive:
Puoi pensare all'architettura evolutiva come una meta-architettura, se vuoi; un'architettura di architetture. Linee guida che dettano i principi di progettazione che promuovono la fusione di oggetti in argilla anziché in pietra.
Sì, è una contraddizione se stai rendendo tutto facile da cambiare indiscriminatamente. Se devi aggiungere del codice per fare qualcosa "più facile da cambiare" (con "più semplice", mal definito, come qui), allora hai reso più difficile cambiare, semplicemente perché hai aggiunto del codice. D'altra parte, se sai esattamente cosa cambierà, il che è altamente improbabile, il codice aggiuntivo non dovrebbe essere visto come una complessità inutile.
Rendere le cose "facili da cambiare" è probabilmente la ragione principale per cui il software moderno è diventato così gonfio e difficile da cambiare.
Leggi altre domande sui tag design agile architecture architectural-patterns