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.
DDD e multi-tenancy in Laravel convivono bene se separi responsabilità e mantieni il dominio indipendente.
Il tenant deve essere un concetto del linguaggio ubiquo solo dove serve (identità, piani, limiti), mentre
la parte “tecnica” (scoping, connessioni, prefissi, provisioning) vive nell’infrastruttura.