aggregazione DDD e struttura dei componenti [chiusa]

Question

aggregazione DDD e struttura dei componenti [chiusa]

#1 da (4 voti)

1

Che cosa pensi che ci sia una relazione tra l'aggregato DDD e la componente architettonica? Penso che sia abbastanza ragionevole pensare che i servizi, che sono legati a specifici aggregati, definiscano una struttura di componenti.

Quando modifico il modello di dominio del mio software, troverei diversi aggregati di domini (con radice aggregata) e, come sai, nella pratica del DDD, ogni aggregato deve gestire come una singola unità. Giusto?

Ora semplificata, la fase successiva è una modellazione della struttura dei componenti di livello superiore e devo scoprire quale tipo di componenti esistono. Quindi potrei considerare che ogni aggregato ha definito un nuovo componente e quel componente fornisce porte o interfacce specifiche per ogni processo aziendale, che gli strumenti aggregati incapsulati?

domain-driven-design architecture component aggregate

posta Toni 26.01.2016 - 22:08

fonte

1 risposta

Leggi altre domande sui tag domain-driven-design architecture component aggregate

C'è un modo per scrivere questo fold neater in Haskell? Algoritmo per ottenere tutti i percorsi in un albero

score 4 · Answer 1

Penso che la risposta a ciò che stai cercando di ottenere sia come identificare i contesti limitati.
Un aggregato a sé stante può infatti essere considerato come un limite di coerenza per tutte le entità e gli oggetti valore racchiusi in. Tuttavia, non esporre le entità direttamente al mondo esterno.

Per applicare in modo efficace DDD inizia identificando i sottodomini. Trova quale di loro è fondamentale, di supporto o generico. Ognuno dei sottodomini di base dovrebbe mappare ottimisticamente un contesto limitato (ad esempio contesto limitato a spedizione in un sistema di e-commerce).

Un contesto limitato può essere composto da diversi componenti aziendali (Shipping.regularShipping e Shipping.priorityShipping).

Ogni componente aziendale può essere ulteriormente suddiviso in componenti correlate al modo in cui ciascun dominio aziendale potrebbe essere implementato. Ad esempio, Shipping.regularShipping potrebbe leggere i dati da una coda, quindi potresti preferire creare un piccolo servizio micro per consumare quella coda e archiviare i dati localmente. Potrebbe essere necessario calcolare la dimensione della confezione, in modo da poter creare un piccolo micro servizio solo per eseguire tale calcolo.

Ogni contesto limitato conterrà diversi livelli. Alcuni di questi livelli saranno suddivisi in porte che sono semplicemente punti di accesso all'applicazione (app Web MVC, interfaccia REST, interfaccia SOAP, chiamate Scheduler). Alcuni chiamano questi i livelli di presentazione o client del tuo contesto limitato.

Il livello di presentazione chiama in un servizio applicativo che mappa il tuo caso d'uso dal tuo dominio. Il livello dell'applicazione chiama nel livello dominio per caricare o creare un aggregato e operare su di esso.

Il livello dominio ospita le entità, gli oggetti valore, i servizi di dominio e le interfacce in tutti i servizi di infrastruttura che prevedi di utilizzare (principalmente l'archiviazione dei dati utilizzando i repository).

Il livello infrastruttura ospita l'implementazione di tutti i servizi tecnici necessari (accesso al database, controllo della cache, crittografia, registrazione, file system).

Potresti trovare Pattern, Principi e pratiche del design orientato al dominio e Implementazione del design basato sul dominio una lettura interessante.