Dominio astratto DDD

Osservazione preliminare sul tuo approccio: attenzione!

Iniziare a modellare un dominio specifico (ad esempio il biglietto aereo) è impegnativo. Cercando di astrarre una parte di questo modello per un futuro riutilizzo potenziale (ad esempio biglietteria ferroviaria, bigliettazione di giochi olimpici, prenotazioni alberghiere, ecc.) Viene fornito con tre rischi significativi:

• Rischio di comunicazione: il tuo modello sarà più difficile da condividere con gli esperti di business. Potrebbero essere confusi con le tue astrazioni. Ciò potrebbe rapidamente provocare la sensazione di non essere capito e potrebbero sorgere tensioni.
• Rischio di accuratezza: gli esperti di business mapperanno mentalmente le entità di ticketing astratte ai concetti concreti che usano nella loro vita quotidiana. Se non prendi le conseguenze di questa confusione semantica, il tuo livello astratto potrebbe rapidamente diventare molto specifico.
• Rischio del progetto: provando a consegnare due cose alla volta, ad esempio un motore astratto e un adattatore concreto, potresti dover affrontare molti altri problemi che potrebbero mettere a repentaglio il tuo progetto principale.

Quando farlo?

Se l'astrazione è fatta solo ai fini di un'implementazione generica, il mio consiglio sarebbe di usare un altro approccio: prima prendi cura del tuo sistema di ticketing iniziale e mantieni pulito il modello di dominio, quindi refactoring.

Tuttavia, il ticketing è un dominio aziendale a sé stante. E alcune pratiche attraversano i confini della loro industria originale. Ad esempio, in Europa, molte società ferroviarie hanno adottato principi (e sistemi) di biglietteria aerea. Alcuni problemi generali come i prezzi dinamici, la gestione dei rendimenti, ecc. Sono anche innovazioni recenti che valgono la pena di essere trattati come concetti di business originali.

Quindi, se la tua astrazione è in realtà sulla modellizzazione di un dominio aziendale più generale, con un valore di business proprio, il tuo approccio potrebbe essere definitivamente giustificato.

Come farlo con DDD?

La situazione che descrivi è in effetti abbastanza comune nei progetti di grandi dimensioni e compex: diversi domini potrebbero dover interagire. Evans si rivolge esplicitamente al suo grande libro blu :

Bounded context: The delimited applicability of a particular model. BOUNDING CONTEXTS gives team members a clear and shared understanding of what has to be consistent and what can develop independently.

È interessante notare che nella parte riguardante la progettazione strategica, nel capitolo 14 dà come esempio un'attività di spedizione e identifica il sistema di prenotazione come un contesto limitato distinto.

Il principio dei contesti limitati è che possono esistere diversi modelli di dominio, ciascuno definito in un contesto limitato. La lingua ubiquitaria si applica all'interno di un contesto.

Per mantenere la visione d'insieme e garantire la coerenza, una mappa di contesto globale deve descrivere i concetti principali dei diversi contesti e mappare oltre i confini il concetto correlato:

Context Map: A representation of the BOUNDED CONTEXTS involved in a project and the actual relationships between them and their models.

Se il link sopra all'articolo di Fowler non è sufficiente, ti consiglio di leggere di più su questo argomento nel libro di Evan. Ne vale sicuramente la pena, se usi professionalmente DDD.

What I am currently trying to do, which I am not sure if it is correct - is decouple the project models from a specific domain, and think of them abstractly. So, instead of airline booking system - it becomes a more abstract ticket booking system.

Perché?

Il tuo dominio dovrebbe essere il luogo in cui vivono le tue regole aziendali. Nessuna delle regole aziendali è specifica per la parte aerea di un sistema di prenotazione di una compagnia aerea? Se no, perché hai lasciato che i dettagli della compagnia aerea nel sistema?

Se alcune regole aziendali hanno bisogno del concetto di "compagnia aerea", allora questo appartiene al dominio. Ho potuto vedere le funzioni del sistema di prenotazione dei biglietti astratti in funzioni di biblioteca che non hanno il concetto di compagnia aerea. Ma questo non prende il controllo del tuo dominio. Supporta il tuo dominio. Spingi la libreria di bigliettazione su un livello esterno.

Posso dire la stessa cosa per i pivot verticali. Se vuoi che ciò sia sottratto alle compagnie aeree o ai sistemi di prenotazione scrivi una libreria pivot verticale e usala. Usalo nel tuo dominio. Basta non usarlo come dominio.

Questo potrebbe sembrare contro intuitivo. Potresti aver pensato che il dominio fosse la parte più astratta in modo che il sistema di bigliettazione ottenesse richieste più astratte che fosse più centrale. Questo non è ciò che è un dominio. Un dominio spinge via ciò che non è focalizzato sull'espressione delle regole aziendali. un DB o una GUI possono essere molto astratti. Non è un motivo per inserirli nel dominio.

Il dominio è dove qualcuno che non comprende i dettagli del sistema ma capisce che l'azienda può guardare e vedere le regole aziendali espresse in una lingua che capiscono.