Issue 10004
Modello canonico vs modello di dominio
Integrare bene i sistemi senza impoverire il linguaggio del dominio
· 5 min
Obiettivo
Capire la differenza tra un modello canonico usato per integrare sistemi e un modello di dominio usato per proteggere regole, linguaggio e decisioni di business.
Quando usarli, e soprattutto quando non confonderli
In pratica, il modello canonico serve a semplificare l’integrazione tra sistemi: riduce i mapping punto-punto e crea una lingua franca per oggetti come cliente, ordine o spedizione. Il modello di dominioGlossarioDominioLa parte del mondo reale, del business o dell’organizzazione che un sistema deve supportare.Apri la voce completa, invece, serve a far vivere bene un contesto applicativo: rende esplicite regole, invarianti e linguaggio locale. La decisione architetturaleGlossarioDecisione architetturaleUna scelta progettuale significativa il cui contesto e i cui effetti devono restare comprensibili nel tempo.Apri la voce completa importante è questa: usa il canonico per l’interoperabilità, non per governare il comportamento interno dei servizi. Se il servizio comincia a ragionare con campi come statusCode o sourceSystemFlag, probabilmente il modello di integrazione sta invadendo il dominio. In quel caso conviene tradurre i concetti esterni verso un linguaggio locale più preciso, spesso con una Anti-Corruption Layer. Per un Solution Architect, il punto non è scegliere un modello “più elegante”, ma capire dove standardizzare e dove proteggere l’autonomia del dominio. • Usa il modello canonico per lo scambio tra sistemi, soprattutto quando i punti di integrazione sono molti. • Usa il modello di dominio dentro il servizio per esprimere regole e linguaggio del business. • Se il canonico entra nelle regole interne, fermati e valuta una Anti-Corruption Layer.
I trade-off reali: meno mapping o meno chiarezza del dominio
Il vantaggio del modello canonico è evidente quando hai molte integrazioni: semplifica il numero di traduzioni e dà una base comune ai team. Il costo, però, è altrettanto reale: se lo usi troppo in profondità, rischi di appiattire differenze importanti tra domini diversi. Il modello di dominio fa il contrario: aumenta la chiarezza locale, ma richiede più traduzioni in ingresso e in uscita. Questo è spesso il prezzo giusto da pagare, perché le regole di business non sono uguali ovunque. Un Customer del CRM, un Account della CDP e un Buyer dell’e-commerce possono condividere alcuni attributi, ma non la stessa semantica. Il trade-offGlossarioTrade-offUno scambio in cui migliorare un risultato ne indebolisce o ne rende più costoso un altro.Apri la voce completa utile da portare in meeting è semplice: standardizzare troppo riduce l’attrito iniziale, ma può generare ambiguità e debito architetturale nel tempo. Proteggere il dominio costa un po’ di più all’inizio, ma evita che la complessità si sposti dentro i servizi. • Più standardizzazione: meno mapping e più velocità iniziale. • Più autonomia del dominio: più traduzioni, ma regole più chiare e sistemi più evolvibili. • Il rischio maggiore è la semantica falsa: oggetti uguali nel nome, diversi nella responsabilità.
Esempio realistico in un programma enterprise
Immagina un gruppo retail con ERP, e-commerce, CRM e un motore di spedizione. Il programma decide di introdurre un modello canonico per Order, Customer e Shipment, così da evitare decine di mapping bilaterali tra i sistemi. La scelta funziona bene nel layer di integrazione: ogni sistema pubblica e consuma messaggi in modo consistente. Il problema nasce quando il team e-commerce prova a usare lo stesso canonico per le regole di checkout. A quel punto compaiono campi generici e ambigui che non aiutano a decidere se un ordine è acquistabile, se un cliente è eleggibile a una promozione o se un reso è consentito. La soluzione più solida è mantenere il canonico come contratto di interoperabilità e lasciare che ogni bounded contextGlossarioBounded ContextUn confine entro cui un modello di dominio e il suo linguaggio mantengono un significato coerente.Apri la voce completa abbia il proprio modello di dominio. L’anti-corruption layer traduce i messaggi canonici in concetti locali, così il servizio resta libero di evolvere senza ereditare terminologia troppo generica. • Il canonico resta nel layer di integrazione. • Il dominio dell’e-commerce mantiene regole e linguaggio propri. • La traduzione tra i due riduce la contaminazione semantica.
Per approfondire
Fonti esterne autorevoli per approfondire la differenza tra modello canonico, dominio e modellazione nei bounded context. • Design Patterns for Data Integration - Martin Fowler - https://martinfowler.com/articles/enterprisePatterns.html • Building Microservices, 2nd Edition - Sam Newman, O'Reilly - https://www.oreilly.com/library/view/building-microservices-2nd/9781492034018/ • Anti-Corruption Layer - Microsoft Learn - https://learn.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer
Tag