ESICONF è la conferenza in cui Peer Network mette a confronto esperienze e approcci sull’evoluzione dei sistemi digitali: architetture, integrazione, modernizzazione applicativa. Un contesto in cui la tecnologia conta, ma conta ancora di più la capacità di renderla governabile e coerente con il business. È in questa cornice che si inserisce l’intervento del Prof. Alessandro Ricci (Università di Bologna), dedicato a un tema tornato centrale: il Domain-Driven Design (DDD).
Perché il DDD torna centrale (e non è nostalgia)
Definire il DDD un “ritorno” è vero solo a metà. Come dice lo stesso professore, più che un ritorno al passato, è un ritorno al futuro: un approccio che ha ormai due decadi, ma che oggi diventa ancora più necessario perché è cambiato il mondo che deve governare. In questi anni sono diventati pervasivi rete, distribuzione, servizi, microservizi, cloud; la complessità, dunque, non è più un evento eccezionale, è la normalità. E quando la complessità diventa sistemica, serve un metodo capace di prenderla “al cuore”, non ai margini.
Il centro del DDD: dominio, linguaggio, separazione
L’idea cardine rimane semplice (ed è proprio per questo potente), ovvero mettere il dominio al centro della progettazione e dello sviluppo. Significa distinguere con chiarezza ciò che è tecnica (stack, infrastruttura, scelte implementative) da ciò che è dominio (concetti, regole, processi, la cosiddetta “business logic”). Senza questa separazione il rischio è costruire sistemi corretti “tecnicamente”, ma fragili sul piano della soluzione al problema.
Da qui discende un secondo pilastro: l’Ubiquitous Language. Un vocabolario condiviso che non serve solo a comunicare meglio, ma a fare in modo che il software resti leggibile e fedele ai concetti del business anche quando cresce, si distribuisce e cambia. L’obiettivo è riconoscere il dominio nel codice e nelle strutture del sistema, evitando che tutto diventi un miscuglio di tecnicismi che col tempo si opacizza.
Il valore emerge ancora di più “a run time”, quando bisogna osservare, gestire, cambiare, evolvere sistemi distribuiti, aperti e dinamici. In questo modo appare evidente che la coerenza concettuale non è teoria ma ciò che rende possibile intervenire con velocità e sicurezza.
Prima il problema, poi la soluzione
C’è anche una presa di posizione netta contro un’abitudine diffusa, quella di partire dalla soluzione tecnica e poi cercare un problema che la giustifichi. Invece, l’ordine corretto è l’opposto vale a dire capire il problema e solo dopo definire le scelte architetturali e tecnologiche.
Questo richiama la disciplina dei requisiti, funzionali e non solo, e la necessità di esplicitare gli attributi di qualità e i criteri con cui misurarli. Quando questa fase manca, il rischio è di correre subito sul “come” (la tecnologia) prima di aver chiarito bene il “cosa” e il “perché” (dominio e obiettivi).
Microservizi e PBC: confini, coerenza, componibilità
Nel passaggio alle architetture moderne è importante sottolineare che “microservizi” non significa semplicemente spezzare un monolite o “containerizzare”. È una scelta architetturale che richiede confini chiari, responsabilità coerenti e una struttura che protegga il dominio e il contesto su cui si applica la soluzione.
In questo scenario, DDD aiuta a progettare microservizi sensati perché fornisce criteri per definire confini e granularità. E qui si innesta il tema delle PBC (Packaged Business Capabilities) una chiave di lettura che porta a un livello più vicino al business e, soprattutto, mette al centro la componibilità applicativa.
Non basta far “parlare” servizi e interfacce, occorre comporre soluzioni in modo coerente con processi e capacità di business. In questa direzione le PBC diventano un razionale utile per ritrovare aggregati e composizioni che vadano oltre la granularità fine tipica dei microservizi, senza perdere controllo.
AI: oltre la generazione di codice, con una condizione
Sul tema dell’intelligenza artificiale, il punto di equilibrio è chiaro: non ridurre tutto al “vibe coding”, ma riconoscere che l’AI può diventare un supporto lungo tutto l’arco dello sviluppo, anche per ragionare su scelte progettuali, alternative architetturali e persino sulla specifica.
Metodo e consapevolezza sono però una condizione non negoziabile; più questi strumenti diventano potenti, più diventa essenziale saper governare tecniche e principi architetturali, altrimenti il rischio è accettare soluzioni che non sappiamo inquadrare, comprendere, controllare.
La chiusura sintetizza bene il passaggio d’epoca: oggi si parla alle macchine con il linguaggio delle persone. Proprio per questo è fondamentale mantenere padronanza del linguaggio e restare al centro del dialogo.
