L'architettura a strati deve ancora essere implementata all'interno di tutti gli altri pattern di architettura come SOA e Microservices?

Riguarda la semantica.

L'applicazione di livelli aiuterà a mantenere il codice pulito nelle responsabilità. (Principio della responsabilità unica). Il tuo stack mentale sarà ridotto al minimo in ogni livello quando si separano le preoccupazioni. E ottieni flessibilità nell'incrociare i livelli.

L'uso dei livelli è il modo verticale per organizzare la massa del codice. E questo è lo stesso con l'organizzazione delle persone. Devi dedicare più tempo all'organizzazione se hai più persone.

Una cosa per i microservizi:

Non indirizzano i livelli, si rivolgono alla via orizzontale (modo funzionale) per organizzare la massa del codice. Ancora una volta: più codice, più separazione. Ma attenzione:

I microservizi possono rinunciare alla coerenza se mancano il contesto "più grande" dell'intero dominio. Quindi, se progetto i microservizi, sono una visione in uscita di parti del mio modello di dominio aziendale considerando la coerenza globale.

Quindi la maggior parte delle volte non dividerei il livello aziendale in parti più piccole in quanto potresti perdere la possibilità di controllare i vincoli globali OPPURE dovrai considerare questi vincoli di coerenza nel tuo protocollo microservice, rendendoli molto più complessi.

Per me UI, Usecases, logica aziendale e livelli DAO sono essenziali e universali nella semantica. Non penso che dovremmo discutere sull'interfaccia utente. Usecases modellerà il flusso di lavoro corrente di un utente. La logica aziendale controllerà i vincoli locali e globali per garantire la coerenza a livello di sistema, inoltre orchestra i DAO. E il livello DAO si astrarrà dal tipo di titolare dei dati.

Dopo tutto, solo una cosa conta: il massimo profitto dell'azienda per cui lavori. Quindi le tue spese per separare le preoccupazioni dovrebbero essere bilanciate con le entrate che raggiungono con l'applicazione al massimo profitto.

La maggior parte dei leader del design guidato dal dominio preferisce allineare i microservizi con il contesto limitato (Eric Evans - DDD e Microservices: At Last , Alcuni confini! e Vaughn Vernon hanno detto utilizzando un approccio basato sul Domain-driven design (DDD) , in particolare i contesti limitati ). Se segui il suggerimento dei leader DDD, non otterrai servizi minuscoli. Ciò significa che è anche utile strutturare attentamente il codice all'interno del servizio.

Tuttavia, come dice Vaughn Vernon nel suo libro IDDD

These days many teams that say they are using a Layer Architecture are actually using Hexagonal instead.

Con un concetto ben accettato del principio di inversione delle dipendenze e una buona dose di supporto all'iniezione in diverse piattaforme, Hexagonal (noto anche come porte e adattatori) è abbastanza facile da implementare.

Nell'esempio di ThumpImageService nella domanda, sembra abbastanza semplice. La domanda è: questo servizio sarà sempre così semplice, per esempio, coinvolgerà nella gestione di altre risorse, avrai diverse immagini di thump per tema / profilo. E un'altra domanda è se la maggior parte dei tuoi servizi sia così semplice. Il punto è che i microservizi o DDD sono meglio da usare per "Affrontare la complessità nel cuore del software". Mi piace molto l'idea di "DDD Scorecard" (nel libro di IDDD). Prima di andare in profondità, dovremmo segnare il progetto e valutare se il progetto vale la pena.

Stai parlando di mele e arance qui quando mischi ui, api, dati o livelli logici con Docker. Docker è un problema di implementazione; i modelli architettonici sono concettuali.

Ciò che il modello di contenitore ti consente di fare è distribuire i singoli livelli dell'applicazione, se così costruita, in singoli contenitori. In teoria è possibile eseguire livelli ui, api, dati o logici in cluster di contenitori Docker collegati in modo sincrono o asincrono. D'altra parte, puoi schiacciare tutti in un unico contenitore se la tua applicazione ha un ingombro molto ridotto.

Quello che devi fare è analizzare innanzitutto cosa stai facendo e poi come che si scompone in componenti logici. Molto dipende da quanto è grande il tuo progetto, i suoi requisiti di scalabilità e affidabilità, così come le realtà di quanto tempo sarà intorno.

I pattern sono solo linee guida che devono essere valutate nel contesto delle tue esigenze. Piccolo progetto per una piccola base di utenti? Si può sprecare un sacco di tempo cercando di avere un'architettura concettualmente elegante, quando il costo non è giustificato dal business case. Grande progetto, più team di sviluppo, lunga vita del prodotto ... quindi un pattern è essenziale, altrimenti ti perderai.

Gli strati architettonici hanno senso non solo per separare i problemi di sviluppo e test, ma anche per implementare sistemi più scalabili. Ad esempio, poiché un livello API deve normalmente essere estremamente resiliente e reattivo, potrebbe essere necessario un cluster più grande di contenitori rivolti all'utente che possano sempre rispondere alle richieste. D'altra parte, potresti avere vari componenti di business logic che sono leggermente utilizzati e quindi possono essere eseguiti in contenitori singoli.

In altre parole: sapere cosa si sta facendo, capire come deve essere distribuito, quindi vedere quali strati architetturali hanno senso per creare un sistema stabile e di lunga durata.