DDD, microservizi e architetture evolutive: sostenibilità architetturale

Architetture che durano

Non esistono architetture perfette. Esistono architetture che durano abbastanza a lungo da restare utili.
E la differenza, spesso, sta nella loro sostenibilità nel tempo, cioè nella capacità di essere:

• comprese,
• adattate,
• evolute,
• manutenute, da persone reali, in contesti reali, sotto vincoli reali.

In altre parole: un’architettura non è sostenibile solo perché è elegante. Lo è se non collassa sotto il peso del tempo.

Sostenibilità non è solo codice

Quando parliamo di “architettura sostenibile”, pensiamo subito al codice, al design, ai pattern.
Ma il codice è solo una parte del tutto.

Una vera architettura sostenibile è:

• documentata quanto basta,
• scoperta più che imposta, emergente dal contesto e dal dominio,
• compresa dal team, non solo da chi l’ha progettata,
• economicamente sostenibile, ovvero non genera un debito che paralizza,
• culturalmente accettabile, cioè compatibile con il mindset e le pratiche dell’organizzazione.

Come nel design industriale, anche nel software l’usabilità e la manutenzione sono parte integrante del valore.

Manutenzione come capacità strategica

Il software è l’unico prodotto umano che non si usura con l’utilizzo, ma con il cambiamento del contesto.
Un sistema può funzionare perfettamente oggi ed essere obsoleto domani, non per bug, ma perché il mondo attorno a lui è cambiato: requisiti, utenti, modelli di business, tecnologie.

La vera sostenibilità nasce quando:

• l’architettura non impedisce il cambiamento, ma lo facilita,
• il team non teme di toccare il codice, perché è comprensibile,
• il debito tecnico è sotto controllo e non si accumula silenziosamente.

Il ruolo del debito tecnico

Il debito tecnico non è un male in sé. Come nella finanza, diventa un problema solo quando non è intenzionale o non viene ripagato.

Un sistema sostenibile:

• accumula debito tecnico in modo consapevole (scelte tattiche),
• ne misura l’impatto (test, metriche di manutenzione, code churn),
• lo riduce progressivamente (refactoring continuo, cicli di miglioramento),
• ne discute apertamente (trasparenza nei backlog, retrospettive tecniche).

Una questione di persone

Non esiste architettura sostenibile senza un team sostenibile.

Una buona architettura è quella che:

• consente onboarding rapido,
• riduce il rischio di conoscenza tribalizzata,
• favorisce la collaborazione tra domini e discipline (dev, ops, business, sicurezza).

I sistemi complessi non falliscono per carenza di astrazione, ma per carenza di comunicazione.

Pratiche per la sostenibilità

Alcune abitudini concrete aiutano a mantenere la rotta nel lungo periodo:

• ADR (Architecture Decision Records)
  Documentare le decisioni architetturali in modo leggero e tracciabile.
• Health Check Architetturali
  Valutazioni periodiche del sistema: cosa sta reggendo? Cosa no? Perché?
• Evolvability Score / Fitness Functions
  Metriche che aiutano a misurare quanto un’architettura supporta il cambiamento.
• Refactoring strutturale continuo
  Non solo miglioramento del codice, ma dei confini tra moduli e contesti.
• Allineamento con il dominio
  L’architettura resta allineata con il business solo se i team parlano con chi vive il dominio quotidianamente.

L’architettura come conversazione continua

Forse l’errore più diffuso è credere che l’architettura sia una decisione da prendere una volta sola.
In realtà, è una conversazione continua: tra persone, tra team, tra codice e realtà.

Un’architettura sostenibile è viva, cioè:

• si adatta senza snaturarsi,
• si evolve senza perdere senso,
• si apre al cambiamento senza collassare.

Conclusione: oltre il design, verso la responsabilità

Abbiamo parlato di DDD, moduli, pattern, eventi, versioni, rollback. Ma alla fine, tutto converge su una sola domanda:

“Questo sistema sarà ancora utile tra sei mesi? Tra due anni? Possiamo evolverlo con fiducia?”

La sostenibilità architetturale non è una tecnica, ma una forma di responsabilità collettiva.
È il frutto di decisioni tecniche consapevoli, cultura del team e collaborazione continua.

E in questo, il Domain-Driven Design non è solo una guida tecnica, ma una lente per vedere meglio il sistema, il contesto, e — soprattutto — le persone che lo abitano.

Nel prossimo e penultimo episodio cercherò di dare la mia personale opinione su un tema che spesso crea confusione: Event Sourcing is not Event Streaming.