Progettazione multi-tenant di microservizi

Penso che l'opzione 2 non sia negativa, ma potrebbe non essere necessaria. I micro servizi ti consentono di gestire le esigenze di più applicazioni.

Un grosso fattore qui è se c'è qualche differenza tra i due schemi e se ci sarà mai in futuro.

Di solito, penso che l'uso di interfacce per repository non sia necessario; tuttavia, potrebbe valere la pena in questo caso. Le fabbriche del deposito saranno importanti per te.

Il mio problema con l'opzione 1 è che è troppo specifico. Dovresti essere in grado di passare dalla configurazione che hai descritto, a due istanze separate ciascuna delle quali punta facilmente al proprio DB. L'applicazione non dovrebbe ATTENZIONE DOVE OTTIENE I SUOI DATI.

Sebbene lo schema non differisca per i due database diversi, è possibile avere un repository facilmente gestibile con entrambi, senza che l'applicazione conosca la differenza:

public class MyEntityRepository : ISavesMyEntity, IGetsMyEntity
{
    public MyEntityRepository(string connectionString)
    {
       _connectionString = connectionString;
    }
}

public class MyEntitySaverFactory
{
    public ISavesMyEntity GetSaver(User user)
    {
        if (user.IsUK)
            return new MyEntityRepository(Config.Get("UKConnString"));
        if (user.IsUS)
            return new MyEntityRepository(Config.Get("USConnString"));
        throw new NotImplementedException();
    }
}

//USE
ISavesMyEntity saver = factory.GetSaver(currentUser);
saver.Save(myEntityInstance);

Se gli schemi DB diverranno mai disparati tra Stati Uniti e Regno Unito, allora divideresti le funzionalità in due repository completamente diversi. Questo sarebbe facile, dato che tutto quello che dovresti fare è cambiare la tua fabbrica.

Vorrei andare con la seconda opzione, dà meno attrito nello sviluppo e nella distribuzione.

Ciò consentirà una migliore scalabilità e disponibilità e migliori opzioni di distribuzione dei tempi di inattività, poiché hai distribuito l'app a 1 (o almeno una) istanza per regione anziché almeno una per il mondo intero.

Man mano che i requisiti cambiano, potresti avere una logica aziendale più specifica della regione e probabilmente anche modifiche ai dati, proverei a suddividere il codice e i dati per regione, evitando di condividere la logica di business specifica della regione (potresti finire per condividere un po 'di core codice).

Ha senso?