Come dividere un progetto DDD in stile cipolla senza utilizzare i microservizi?

Question

Come dividere un progetto DDD in stile cipolla senza utilizzare i microservizi?

#1 da (0 voti)

-1

Sfondo: Sto costruendo un prototipo di app scientifica con le parti "Esplorazione" e "Ottimizzazione". (Altre parti potrebbero essere necessarie in seguito.) Ogni parte utilizza la programmazione reattiva funzionale (FRP) e ha una propria finestra GUI. "Ottimizzazione" dipende dalle scelte dell'utente all'interno di "Esplorazione"; non c'è dipendenza dall'altra parte Anche se il linguaggio è Scala, in futuro sarà necessario integrare con Python e possibilmente R.

In primo luogo, ho creato una "Esplorazione", solo un'app basata sull'architettura "pulita" e sui principi del DDD. (L'app è implementata come progetto sbt multi-modulo in Intellij, vedi Figura 1.) Sono contento di questa app individuale.

Figura 1: "Esplorazione" -solo progetto con i "moduli cipolla" ombreggiati. Dipendenze omesse: principale su ogni modulo; ogni modulo su Utils.

I problemi sono iniziati quando si aggiunge la parte "Ottimizzazione" allo stesso progetto Intellij. In termini DDD, "Esplorazione" e "Ottimizzazione" sono distinti contesti limitati. Combinare entrambi in un progetto richiederebbe due "cipolle" affiancate. La complessità è notevolmente maggiore rispetto al progetto "Esplorazione" - solo.

Provato: ho esaminato i microservizi, che sembrano interessanti, ad esempio, per separare contesti limitati link , ma presenta anche degli svantaggi link ; link . Dato che ho poca esperienza con loro, probabilmente sono un eccesso per questo prototipo di medie dimensioni, ma potrebbero essere utili in futuro.

La mia idea attuale è quella di dividere il progetto in quattro progetti multi-modulo separati; vedere la Figura 2. Il "Progetto principale" indipendente contiene tutti i domini di supporto e il dominio principale astratto. I progetti "Esplorazione" e "Ottimizzazione" dipendono da questo come un progetto esterno. Il progetto "Principale", dipendente dagli altri tre, collega l'intera applicazione ed è responsabile del trasferimento dei dati da "Esplorazione" a "Ottimizzazione".

Domanda: questa soluzione è ragionevole e come potrebbe essere migliorata? O c'è una soluzione migliore?

Correlati: Diverse domande SE suggeriscono l'utilizzo dei microservizi, ad es. Come si può separare un monolite nelle librerie basate su domini senza duplicare le interfacce e mantenere le dipendenze semplici? . Ci sono anche domande specifiche per la lingua, ad es. Microservizi e librerie condivise per Python.

Figura 2: Dividi in 4 progetti esterni. Le dipendenze tra progetti (linee tratteggiate) puntano verso l'alto

design domain-driven-design clean-code architecture microservices

posta Tupolev._ 06.05.2018 - 18:01

fonte

1 risposta

Leggi altre domande sui tag design domain-driven-design clean-code architecture microservices

Dati di addestramento nell'apprendimento non supervisionato? Come mostrare il flusso di dati tra entità in un diagramma di flusso di dati quando i dati di input e di output sono gli stessi?

score 0 · Answer 1

Vedo molta confusione nella tua domanda, quindi prima un po 'di background: contesti limitati (BC) separano le aree di interesse in un modello di dominio e cancella la confusione in un sistema di grandi dimensioni. Un BC è anemico (mal definito) se non si dispone di una mappa di contesto. La separazione logica esiste perché devi tradurre i concetti in un contesto limitato in altri concetti in un altro. Il più grande aiuto arriva quando devi mappare un termine in un contesto limitato allo stesso termine in un altro contesto limitato.

Nell'implementazione, utilizzerai l'inversione di dipendenza, i servizi e gli eventi di dominio per disaccoppiare il tuo dominio dalla tua piattaforma. I framework GUI, i servizi Web e i database sono tutti domini separati dal dominio aziendale. È l'interazione del dominio aziendale (dominio problematico) con tutti questi domini di implementazione (domini della soluzione) che è uno dei principali responsabili della complessità accidentale nei sistemi. Questo è il motivo per cui l'architettura delle cipolle è eccezionale perché mette queste preoccupazioni al centro.

Sembra che tu stia cercando di organizzare il tuo codice introducendo un sacco di complessità accidentale nel tuo sistema. Dalla tua affermazione sul problema:

Problems started when adding the "Optimisation" part to the same Intellij project. In DDD terms, "Exploration" and "Optimisation" are distinct bounded contexts. Combining both in one project would require having two "onions" side-by-side. The complexity is noticeably greater than with the "Exploration"-only project.

Hai solo bisogno di una cipolla. È possibile inserire tutti i punti di accesso al servizio Web in una singola cipolla come si desidera. La separazione fisica riguarda la distribuzione, le istanze, il ridimensionamento, il coordinamento con team diversi, aggiornamenti continui, orchestrazione, ecc. Sembra che tu stia "programmando nel piccolo" ma ti preoccupi di "programmare i grandi problemi".

Pensa ai tuoi concetti DDD come al tuo modo di progettare un piccolo pezzo del tuo sistema. L'architettura della cipolla è su una scala più ampia che include l'intero sistema. Puoi usare DDD su domini di applicazioni (soluzioni) nel tuo sistema per elaborare interazioni complesse, ma questo è un po 'fuori mano.

Penso ai servizi web più simili ai reali servizi di applicazione DDD. Sono più comportamentali e incapsulati. Utilizzare i servizi Web di separazione comandi-query per esporre viste "di sola lettura" del modello di dominio per le proprie interfacce. I contesti limitati possono essere rappresentati come percorsi secondari sotto una singola rotta di servizio web se si vuole andare in quella direzione.