Dominio "trasversale" in DDD

Question

Dominio "trasversale" in DDD

#1 da (2 voti)
#2 da (2 voti)
#3 da (0 voti)

4

Recentemente ho iniziato a studiare Domain Driven Design e finora sembra che possa aiutare enormemente il progetto attuale del mio team. Mi sto imbattendo in un piccolo problema, anche se effettivamente determino quali sono i domini nel nostro progetto.

Dopo il mio passaggio iniziale, mi sono ritrovato con qualcosa del genere:

Hotredomini:A,BeCperdiverseareedell'azienda.Tuttavia,perognunodiquestihobisognoditracciareidatiattualiedicrearepianiperilfuturo.CiòmihaportatoadaggiungereundominioPlanning,manonvedounmodochiaropersepararePlanningdaglialtridomini.OA,BeCdevonoavereunaconoscenzadettagliatadiPlanningoviceversa.

Esempio:supponiamocheildominioAsia"inventario". L'implementazione ha messaggi per cose come ItemsAdded e ItemsRemoved e tiene traccia delle quantità di vari prodotti. Quindi, se voglio consentire la pianificazione di quantità future di elementi, ho bisogno di aggiungere classi al modello che mi permetteranno di associare future informazioni sui prodotti con varie finestre temporali. Questo tipo di sentirsi come un nuovo dominio ad eccezione della stessa pianificazione e logica della finestra temporale si applica anche al dominio B e C.

Essentialy, ho un dominio trasversale. Mi sembra di doverlo guardare nel modo sbagliato.

Forse ho effettivamente 6 domini e una libreria usata da 3 di loro?

domain-driven-design domain-model

posta takteek 09.07.2014 - 06:36

fonte

3 risposte

Leggi altre domande sui tag domain-driven-design domain-model

Come gestisci specifiche eccezioni di rete in Haskell? Pro e contro delle eccezioni personalizzate [duplicato]

score 2 · Answer 1

2

Che cosa ti impedisce di creare un "Dominio di pianificazione" e altri 3 dipendono da questo dominio? Questa dipendenza sembra abbastanza normale nella libreria / modulo.

risposta data 09.07.2014 - 08:26

fonte

score 2 · Answer 2

Il dominio trasversale può essere un sintomo del dominio del kernel condiviso. Questo è coperto sia dai libri di Evans che da quelli di Vernon.

Ma attenzione, questo dominio Shared-Kernel non dovrebbe essere creato per ispirazione funzionale, ma un dominio che i contenuti sono rilevanti per altri domini - e non perché faccia qualcosa di utile per entrambi.

Si sta tentando di creare un dominio Shared-Kernel che soddisfi un ruolo funzionale, rendendo quindi il sistema strettamente accoppiato invece che liberamente accoppiato. Un grande no-no per la scalabilità del codice sorgente.

score 0 · Answer 3

Ovviamente non capisco il tuo dominio con abbastanza informazioni, ma pianificarmi sembra un dominio completamente separato dal resto del tuo sistema.

Questo dominio ha le operazioni / regole / comportamenti per pianificare le cose, per esempio, puoi pianificare gli oggetti dal tuo inventario, ma dal punto di vista della pianificazione questo non è "articoli di inventario" sono qualcosa come "planItems" forse. Probabilmente non hai bisogno di tutte le informazioni di un articolo di inventario per la pianificazione, perché vuoi utilizzare queste classi di articoli di inventario nel tuo dominio di pianificazione?

Per me questa è una cosa fondamentale per comprendere DDD e fare una corretta separazione in contesti limitati, la stessa "cosa" può essere vista completamente diversa da domini diversi, puoi avere un InventoryProduct nel dominio di inventario e un PlannedProduct o PlannedItem nei domini Planning, questi oggetti possono avere lo stesso id o forse condividere un piccolo insieme di campi (informazioni di identificazione come id, nome ecc. ecc.) ma avere un insieme di operazioni completamente diverso e dati completamente diversi, in un caso i dati che l'inventario ha bisogno nell'altro caso dei dati di cui ha bisogno la pianificazione.