Sempre più spesso mi trovo a ripetere (e convincermi) che il database deve essere un servizio al servizio 🙂 dell’applicazione e non viceversa. In ottica DDD questa affermazione diventa ancora più forte: “il database è mio e lo gestisco io” (semi cit.)
Molto spesso però, questo modo di vedere le cose stride (eufemismo) con la forma mentis dei DBA e di chi deve gestire i dati. Ma non solo…il pensiero di non poter gestire il database ed i suoi dati sembra precludere qualsiasi forma di estensione ed apertura ad altre applicazioni all’utilizzo delle informazioni in nostro possesso. Sembra quasi che aprire, in sola lettura, le tabelle del nostro database ad altre applicazioni significhi avere un’architettura facilmente estendibile ed integrabile.
Bene…anzi male, molto male. Questo significa complicare ancora più le cose e rendere sempre meno rifattorizzabile il nostro database: adesso la modifica anche di un solo campo di una tabella “condivisa” non impatta solo sulla nostra applicazione, ma anche su tutte quelle a cui abbiamo permesso di attingere direttamente ai nostri dati. Un’operazione di questo genere significa non poter evolvere il database (dove per evolvere intendo anche correggere errori fatti in fase di sviluppo) e visto che il database è parte della nostra applicazione significa avere un debito tecnico costante che non potrà fare altro che aumentare nel corso dello sviluppo.
Se altre applicazioni hanno bisogno di “vedere” i miei dati, mi fanno la cortesia di chiedermeli (con gentilezza) ed, eventualmente, sarò ben lieto di metterglieli a disposizione senza l’obbligo di dovergli dire come e dove li ho “storati” e quindi senza l’obbligo di non poter cambiare più.
Queste false credenze mi ricordano tanto la sensazione di aver sviluppato un’applicazione distribuita semplicemente facendo “Add service reference” al nostro progetto da Visual Studio…ma questa è un’altra storia.
