DDD e multi-tenancy non sono in conflitto: anzi, DDD aiuta a mantenere coerenza e chiarezza quando i requisiti di isolamento e variabilità crescono. La chiave è separare bene le responsabilità: dominio pulito e ricco, applicazione che coordina e valida, infrastruttura che applica enforcement non negoziabile (filtri, vincoli, policy DB) e una suite di test che rende l’isolamento un requisito verificabile.
Domain-Driven Design e multi-tenancy non sono in conflitto: DDD aiuta a evitare che il tenant diventi una “variabile globale”
non controllata. Definendo confini (bounded context), value object per il tenant, repository che impongono lo scope
e, dove possibile, RLS nel database, ottieni un sistema più sicuro, coerente e facile da evolvere.
Domain-Driven Design e multi-tenancy possono convivere bene se tieni separati i livelli: il dominio rimane focalizzato su invarianti e comportamenti, mentre la multi-tenancy viene applicata tramite contesto applicativo, repository rigorosi e difesa in profondità nel database.
Con DDD puoi mantenere il dominio pulito,
e spostare l’isolamento dove è più efficace: pipeline di richiesta, repository, vincoli DB e processi di integrazione. La chiave è rendere la tenancy
un’invariante verificabile: non un accordo implicito tra sviluppatori, ma una proprietà del sistema sostenuta da codice, policy e test.