Contesti mappatore Supercontesti: disaccoppiamento di contesti limitati specifici di dominio e generici di dominio

(1 agosto 2019)

Stai creando un nuovo sistema e due membri del tuo team propongono architetture alternative per linvio delle notifiche. Quale è corretto?

Il primo sviluppatore propone un modello push: i contesti limitati dovrebbero indicare al contesto delle notifiche di inviare una notifica. Il contesto delle notifiche (Notifiche) deve semplicemente obbedire ai comandi di altri contesti e inviare notifiche quando richiesto.

Il secondo sviluppatore non ama il modello push e propone una soluzione coreografata: quando i contesti limitati generano eventi Le notifiche dovrebbero ascoltare e determinare quando inviare una notifica.

Come progetteresti la soluzione? Ancora più importante, come risolveresti questa decisione nel team? Come progetterai larchitettura più efficace che supporti gli obiettivi a breve termine e levoluzione a lungo termine?

Avere competenze DDD nel team è un grande vantaggio. Essere in grado di analizzare il tuo dominio per comprendere le capacità principali, di supporto e generiche ti consente di fare buoni compromessi ingegneristici.

Esploriamo ulteriormente questo scenario con una prospettiva DDD.

Dominio Analisi delle capacità

Largomento dellopzione 1 (comandi inviati) è che il generico (notifiche) non dovrebbe dipendere dallo specifico. Se qualcosa è generico in molti domini, logicamente è sbagliato se è accoppiato a qualcosa in un singolo dominio.

Guardando oltre il ragionamento astratto, su cosa ci avverte questa euristica? Quali sono le conseguenze ingegneristiche di cui dobbiamo essere consapevoli?

Ci sono due scenari che vogliamo evitare:

  1. Evitare che la logica specifica del dominio fuoriesca in contesti generici con conseguente co -cambia
  2. Incapacità di riutilizzare o sostituire contesti generici con una soluzione pronta alluso a causa di un accoppiamento troppo stretto con contesti limitati specifici del dominio

Accoppiamento di dominio e responsabilità generiche

Con lopzione 1, non vi è alcun cambiamento congiunto tra API specifiche per dominio e API generiche per dominio. Se è necessaria una nuova notifica, cambiano solo i contesti specifici del dominio. Ma questo non è il caso dellopzione 2.

Con lopzione 2 (coreografata), se viene introdotto un nuovo evento che richiede notifiche, unAPI specifica del dominio dovrà pubblicare il nuovo evento e il servizio di notifiche dovrà iscriversi allevento e inviare una notifica. Questo non sembra corretto: la conoscenza del dominio si nasconde allinterno del contesto generico.

Isolamento delle capacità generiche

Se il servizio di notifiche è veramente generico e riutilizzato da molti team o anche da un organizzazione, dovrà conoscere centinaia di eventi di dominio. E con così tanti team che dipendono dal contesto delle notifiche, diventerà sicuramente un collo di bottiglia riducendo il suo potenziale di riutilizzo in unorganizzazione.

Un altro feedback di progettazione è che non possiamo sostituire il contesto generico con un soluzione pronta alluso. Se è veramente generico in molti domini, ma non possiamo sostituirlo con una soluzione pronta alluso che ha più funzionalità e costa meno da eseguire, il design sta dando un feedback che qualcosa non va.

Quindi i comandi da specifici a generici sono una best practice?

Tutte le prove suggeriscono che lopzione 1 è corretta: i contesti specifici del dominio dovrebbero inviare comandi a contesti generici del dominio per separarli dalla logica del dominio. Tuttavia, la nostra analisi è stata superficiale. Dobbiamo analizzare ulteriormente il dominio per darci la certezza che stiamo facendo buone scelte ingegneristiche.

Analisi più approfondita del dominio

Osservando più da vicino lopzione 1 (istruzioni specifiche generiche), ogni dominio -contesto specifico che deve inviare notifiche ha assunto una responsabilità aggiuntiva. Deve sapere quando inviare le notifiche e che tipo di notifica inviare.

È sensato avere la logica delle notifiche sparsa in tutti i contesti limitati? Insieme al codice ingarbugliato, ciò potrebbe significare un coordinamento su larga scala tra molti team se lapproccio alle notifiche cambia.

Cè anche un aumento del rischio o delle incongruenze e della duplicazione / spreco se ogni team adotta il proprio approccio alle notifiche. Le biblioteche condivise sono una possibilità, ma non risolvono tutti i problemi e portano anche a compromessi.

Alcuni concetti di dominio si dividono chiaramente (triangoli rossi, grigi, gialli; cerchi blu) ma alcuni hanno si sovrappongono a dimensioni diverse e possono essere classificati in più modi (triangoli blu)

Ogni volta che è difficile decidere se una responsabilità debba appartenere a un contesto o a un altro, ingrandire e scomporre ulteriormente la responsabilità. Cerca sotto-responsabilità che possono essere scomposte, forse esiste un concetto di dominio nascosto.

Quando un concetto non si adatta perfettamente a un singolo contesto delimitato, analizzalo ulteriormente per identificare le sotto-responsabilità. Forse esiste un concetto di dominio nascosto che può produrre un modello con partizioni pulite.

Ingrandendo la controversa responsabilità dellinvio di notifiche, potrebbe mancare un concetto ? Forse esiste un terzo concetto che collega il dominio specifico al dominio generico per fornire un modello più elegante.

Contesti del mapping di dominio

Un modello che può essere utilizzato per disaccoppiare lo specifico del dominio e domain-generic è il Domain Mapper Context. Quando un contesto assume questo ruolo, ascolta eventi di dominio specifici e li mappa su comandi inviati a un contesto generico.

Nota come i compromessi di questo modello si confrontano con i pro ei contro delle due opzioni iniziali. Offre i vantaggi di entrambi: libertà di modificare il modo in cui vengono inviate le notifiche senza ingombrare ogni contesto specifico del dominio con la complessità correlata alle notifiche.

Considera lo scenario: un sistema di notifiche interno deve essere sostituito da una soluzione pronta alluso. Il mappatore di domini instraderà tutti i comandi al nuovo servizio di notifiche, senza che alcun contesto specifico del dominio venga influenzato.

Considera un altro scenario: deve essere aggiunta una nuova notifica. Una registrazione verrebbe configurata allinterno del mappatore: quando {evento dominio} attiva {notifica}.

Le notifiche sono una funzionalità generica per il dominio: molti domini sfruttano le notifiche push e e-mail
Preferenze di notifica su Twitter – mappatura da evento specifico del dominio ad azioni generiche di dominio (email)

Perché vengono chiamati Mapper Contexts?

Il la denominazione di questo modello è significativa. Le azioni che avvengono allinterno di un dominio vengono mappate su azioni che avvengono in un altro dominio (un contesto generico è generico in molti domini, quindi è parzialmente in un altro dominio).

È possibile somiglianze con altri modelli come traduttore di messaggi , tuttavia la traduzione implica una certa equivalenza; il valore tradotto è una diversa rappresentazione del valore originale. Con un mappatore, questo non è il caso.

Un mappatore è più un ascoltatore, che osserva ciò che accade allinterno del dominio. Prende una decisione su come rispondere agli eventi nel dominio con unazione in un altro dominio.

Contesti del mapping del dominio del gateway

Se decidi di sostituire il tuo contesto generico con una soluzione SaaS, il contesto del mapping del dominio diventa un contesto del mapping del dominio del gateway.

A Il gateway si trova ai margini di un sistema che gestisce lafflusso e il deflusso di informazioni

Un contesto di mappatura del dominio gateway svolge essenzialmente la stessa funzione, tuttavia, ora si trova a il perimetro del sistema e comunica attraverso i confini del sistema. È un percorso per le informazioni che fluiscono dentro e fuori dal sistema.

Limplementazione può sembrare la stessa, ma avere una terminologia più precisa è utile per consentire di comunicare più chiaramente la tua architettura.

Compromessi ingegneristici di Domain Mapper

I pattern associati ai contesti di Domain Mapper non sono insignificanti. Il livello di mappatura aggiuntivo significa che ora sono coinvolti tre collaboratori. Altre cose che possono fallire.

Cè anche un co-cambiamento. Quando vengono introdotti nuovi eventi o gli eventi esistenti cambiano, devono essere modificati sia i contesti specifici del dominio che possiedono gli eventi sia il contesto del mappatore.

Esistono soluzioni ampiamente utilizzate per ridurre al minimo questi costi.

Contesti del mapping di dominio self-service

Un modello che si verifica frequentemente in natura è il contesto delimitato self-service. Un contesto limitato che gioca questo ruolo consente ai consumatori di sfruttare le capacità del contesto senza essere bloccati dal team che possiede il contesto.

La prima variazione è un meccanismo di compilazione tramite il controllo del codice sorgente e la seconda è un meccanismo di runtime tramite Chiamate API.

Nello scenario delle notifiche, il contesto self-service potrebbe fornire un DSL. I team che possiedono contesti specifici del dominio creerebbero una richiesta pull contenente modifiche in un file di configurazione (ancora meglio – codice che viene compilato e testato), che utilizzando il DSL, configura una mappatura tra un evento di dominio a cui iscriversi e una notifica a essere inviato.

Con la versione dinamica, la configurazione corrispondente verrebbe eseguita tramite una chiamata API o UI. Quando la configurazione dinamica è possibile e non ci sono dipendenze in fase di compilazione dal dominio, il contesto si sposta per diventare completamente generico. Questo è un modello evolutivo comune ().

Linguaggio pubblicato

Un altro modello DDD da considerare in questo tipo di scenario è il linguaggio pubblicato. Qualsiasi evento che attivi una notifica dovrebbe far parte di una lingua pubblicata.

Una lingua pubblicata è un contratto o un accordo sul formato dei messaggi prodotti da un contesto limitato. Garantire che gli eventi che richiedono una notifica facciano parte di una lingua pubblicata significa che è necessario prestare maggiore attenzione per garantire la compatibilità con le versioni precedenti e informare i consumatori delle modifiche future.

Devo sempre utilizzare i contesti del mapping dei domini?

Assolutamente no. Ciascuno dei modelli presentati nel post è valido e utilizzato con successo in una varietà di sistemi. I contesti dei mapping di dominio sono un altro modello con chiari compromessi che puoi utilizzare per esplorare possibilità di modellazione alternative.

La ricerca di supercontesti

È facile modellare domini a livello ingenuo o superficiale . Quando si sente una parola come “notifiche”, è facile cadere nellerrore del nome coerente, supponendo che, poiché una parola suona come un singolo concetto, deve essere rappresentata da un unico contesto delimitato nel nostro sistema.

Quando utilizziamo DDD per analizzare a un livello più profondo e cerchiamo di separare concetti specifici del dominio e generici del dominio, spesso scopriremo che ci sono più modi per modellare il dominio, incluso avere più contesti limitati, delineando il dominio specifico dal generico – allinterno di un unico supercontesto.

Separare lo specifico del dominio dal generico del dominio non significa creare bellissimi modelli astratti che seguono le antiche regole DDD, ma disaccoppiare concetti che cambiano insieme per ragioni diverse in modo da poter progettare il commercio -off che consentono ai sistemi di evolversi più facilmente.

Cerca di evitare lerrore di classificazione del dominio singolo: supponendo che una capacità di alto livello, Notifiche, debba avere una classificazione di dominio singolo (ad esempio generica).

In orde Per ottenere informazioni più approfondite sul dominio, consiglio di portare le competenze DDD e le attività DDD nel modo di lavorare del tuo team. Sperimenta con EventStorming e (The Bounded Context Design Canvas) come punto di partenza per imparare a modellare contesti delimitati meglio.

Formazione e consulenza

Se cerchi aiuto per esplorare il tuo dominio, progettando il tuo sistema o formando i tuoi team, contattami per ulteriori informazioni. Lavoro con una rete di professionisti DDD di grande esperienza che sono appassionati di progettazione di sistemi sociotecnici efficaci in linea con gli obiettivi e il dominio aziendale.