Lavoro con una grande applicazione web monolitica che ha tra 12-24 moduli funzionali e questi sono tutti mantenuti all'interno di una singola struttura di progetto di guerra. Mentre il codice stesso è già segmentato in pacchetti ben definiti e indipendenti, ci sono implicazioni per la distribuzione di una singola applicazione web in questo modo, dal ridimensionamento alla manutenibilità e così via; molto di ciò che la maggior parte dei difensori del settore dice è problematico con questo tipo di progettazione architettonica.
Voglio suddividere questa applicazione monolitica in componenti di implementazione più piccoli, ma ci sono alcuni problemi che rendono questo problema difficile da comprendere.
Modello di dominio
Quasi tutte le nostre classi di modelli di dominio hanno alcune relazioni con altre classi di modelli di dominio di altri moduli. Ad esempio, un prodotto contiene una relazione con un utente che ha creato il record e l'utente risiede in un modulo comune mentre il prodotto è in inventario.
Molti difensori dei microservizi tendono a suggerire che ciascun microservizio sia autonomo e abbia il proprio set di risorse. Ciò implicherebbe il proprio database, in generale, ma uno schema autonomo in un database condiviso è possibile. Sappiamo che le chiavi esterne sono disponibili oltre i limiti dello schema, ma certo non quello dei database.
La domanda diventa quindi se il Prodotto deve semplicemente memorizzare l'ID o il nome dell'Utente e quindi chiamare il servizio Utente per ottenere i dettagli dell'utente se un punto finale richiede dati aggiuntivi anziché imporlo tramite chiavi esterne?
Web / UI
Nel nostro caso, ci sono spesso momenti in cui le imprese vogliono acquisire punti dati aggiuntivi che richiedono non solo una regolazione dell'interfaccia utente, ma un modello di dominio regolare. Quindi, la Web / UI dovrebbe essere inclusa insieme al microservice e le sue classi di modelli di dominio in un singolo artefatto deployable? Esiste un accoppiamento intrinseco tra questo codice, ma l'accoppiamento tra gli strati si basa su contratti di interfaccia ben definiti.
Suppongo che la questione sia quindi intorno alla scalabilità. Se i due sono stati distribuiti separatamente, il servizio di back-end o la Web / UI potrebbero essere ridimensionati in modo indipendente laddove, poiché la distribuzione congiunta non consentirebbe tale progettazione.