Qual è il processo che usi per determinare il contesto limitato in DDD?

3

Ho avuto alcune iterazioni di DDD con alcuni progetti diversi, tuttavia continuo a lottare con la definizione appropriata dei contesti limitati. Mi trovo continuamente a voler creare aggregati molto granulari. Questo è diventato ancora più vero una volta che ho introdotto l'event sourcing nel mix.

Ecco un esempio concreto. Diciamo che sto progettando un software come Photoshop. Fin dall'inizio, posso vedere che avrò un oggetto dominio per il Design. Ora tutti dicono che non progettano domini che non possono reggersi da soli. Questo è dove lotto. Se volevo aggiungere una funzione alla mia applicazione simile a Photoshop per supportare più livelli nel design, il concetto di un livello non ha senso al di fuori del Design. Non "regge da solo". Quindi mi sembra che dovrebbe essere un oggetto di valore del design. La stessa cosa vale per gli elementi grafici reali che possono essere inclusi in un livello. Ma non ha molto senso, perché Value Objects dovrebbe essere immutabile.

Sto cominciando a chiedermi se sto interpretando la frase "stand alone" in modo errato. Ciò significa in realtà che l'oggetto dominio può essere manipolato al di fuori del contesto degli altri domini. Quello che preferirei fare è fare in modo che Design, Layer ed Element abbiano tutti i propri Oggetti Dominio, che mantengono riferimenti l'uno con l'altro da Id. Dal momento che sto andando verso il basso nel percorso ES, pubblicheremo quindi gli eventi del dominio interessato e un ascoltatore aggiornerebbe le relazioni tra questi domini.

C'è un percorso diverso in cui dovrei essere o una diversa interpretazione del DDD?

    
posta aasukisuki 17.10.2017 - 15:36
fonte

2 risposte

2

C'è in effetti un po 'di confusione lì intorno; il termine "si regge da solo" è troppo sfumato per essere d'aiuto.

In primo luogo, due definizioni DDD di base fornite nel libro di Evan:

VALUE OBJECT: An object that describes some characteristic or attribute but carries no concept of identity.

ENTITY: An object fundamentally defined not by its attributes, but by a thread of continuity and identity.

Diamo un'occhiata a Layer : gli elementi grafici reali possono essere inclusi in un Layer . Suppongo quindi che Layer abbia un'identità: se cambi il nome di Layer , come in Photoshop®, tutti gli oggetti che erano in quel livello sono ancora lì, nel livello rinominato. Conclusione: Layer è un'entità.

Ora, il Layer può stare da solo? Bene, lo strato non dipende dagli oggetti in esso contenuti. Tuttavia, nel tuo esempio, il livello dovrebbe essere qualcosa di completamente indipendente che esiste in tutti i grafici che il tuo software manipola? O il livello è qualcosa che esiste solo all'interno del grafico specifico in cui è stato creato? Altrimenti, quando inizi una nuova grafica, i livelli sono già presenti e condivisi con altri elementi grafici oppure inizi con un nuovo livello predefinito? Penso che sia certamente il secondo caso: quindi Layer è di proprietà di Graphic .

AGGREGATE: A cluster of associated objects that are treated as a unit for the purpose of data changes. External references are restricted to one member of the AGGREGATE, designated as the root. A set of consistency rules applies within the AGGREGATE’S boundaries.

Quindi nel tuo modello, Graphic sarebbe certamente la radice aggregata e il Livello sarebbe un'entità in quell'aggregato.

Infine, il contesto limitato sarebbe il tuo dominio per un editing grafico. Nel vostro modello questo rimarrebbe sicuramente l'unico contesto limitato, a meno che non estendiate il modello, con un dominio relativamente indipendente per l'acquisizione del movimento 3D, che non si baserebbe sul modello grafico e quindi starebbe in piedi da solo.

    
risposta data 17.10.2017 - 20:39
fonte
3

La definizione di Contesto Limitato non è affatto sfocata ed è estremamente utile. Questa è l'essenza della DDD e finché non avrai l'idea, probabilmente lotterai per comprendere il valore di questo approccio.

Una delle definizioni di Domain-Driven Design è:

Developing Ubiquitous Language within Bounded Context

Il Contesto Limitato è dove la terminologia della tua lingua ha lo stesso significato. L'esempio classico è il concetto di prodotto nell'eCommerce, che può essere:  - Descrizione e foto nel contesto del catalogo di prodotti  - Peso, dimensioni e dettagli della confezione nel contesto di consegna  - Prezzo nel prezzo o nel contesto di vendita  - Livello di magazzino nel contesto Gestione magazzino

Ciascuno di questi contesti deve avere una vista separata sullo stesso oggetto fisico, che è limitato dall'interesse esplicito di quel contesto. L'idea principale è che il tuo sistema non può avere un modello olistico, invece è costituito da più modelli, che si concentrano sulla rappresentazione della propria visione sul mondo reale.

Contesto limitato consente di suddividere il sistema in componenti singoli e autonomi. Puoi assegnare diversi team per lavorare in diversi contesti. È possibile creare servizi allineati con i limiti del contesto. In realtà diventa evidente che cos'è DDD.

    
risposta data 18.10.2017 - 13:09
fonte

Leggi altre domande sui tag