Potete suggerire le best practice DDD

Question

Probabilmente domande simili sono state poste molte volte, ma penso che ogni risposta aiuti a rendere la comprensione della DDD sempre migliore. Vorrei descrivere come percepisco certi aspetti del DDD. Ho alcune incertezze di base intorno ad esso e apprezzerei se qualcuno potesse dare una solida e pratica ansiosa. Si prega di notare che queste domande assumono un approccio "classico" alla DDD. Ciò significa utilizzare gli ORM, ecc. Approcci come CQRS e sourcing di eventi non sono considerati qui.

1. Aggregati e entità sono gli oggetti principali che implementano la logica di dominio. Hanno uno stato e un'identità. In questo contesto, percepisco la logica del dominio come l'insieme di tutti i comandi che mutano quello stato. Ha senso? Perché la logica del dominio riguarda esclusivamente lo stato? È legale modellare oggetti di dominio che non hanno identità o stato? Perché un oggetto dominio non può essere implementato come uno script di transazione? Esempio: considera un oggetto che ti consiglia un partner per un sito di appuntamenti. Quell'oggetto non ha uno stato reale, ma ha un bel po 'di logica di dominio? Inserirlo nel livello di servizio implica che il modello di dominio non possa coprire tutta la logica.

2. Accesso ad altri oggetti del dominio. Gli aggregati possono accedere a un repository? Esempio: quando un oggetto dominio (stato) deve avere accesso a tutti gli "utenti" del sistema per eseguire il proprio lavoro, è necessario accedervi tramite il repository. Di conseguenza, un ORM dovrebbe iniettare il repository durante il caricamento dell'oggetto (che potrebbe essere tecnicamente più impegnativo). Se gli oggetti non possono avere accesso ai repository, dove inseriresti la logica del dominio per questo esempio? Nel livello di servizio? Il livello di servizio non dovrebbe avere nessuna logica?

3. Gli aggregati e le entità non dovrebbero parlare con il mondo esterno, sono solo preoccupati del loro contesto limitato. Non dovremmo iniettare dipendenze esterne (come IPaymentGateway o IEmailService) in un oggetto di dominio, questo farebbe sì che il dominio gestisca le eccezioni che provengono dall'esterno. Soluzione: un approccio basato sugli eventi. Come spedisci gli eventi allora? Devi comunque iniettare gli "ascoltatori" corretti ogni volta che istanzia un oggetto dominio. Gli ORM riguardano il ripristino dei "dati", ma non sono intesi principalmente a iniettare dipendenze. Abbiamo bisogno di un mix DI-ORM?

4. Oggetti dominio e DTO. Quando si interroga una radice aggregata per il suo stato, viene restituita una proiezione del suo stato (DTO) o degli oggetti del dominio stessi? Nella maggior parte dei modelli che vedo, i clienti hanno pieno accesso al modello di dati del dominio, introducendo un profondo accoppiamento con la struttura effettiva del dominio. Percepisco il "grafico dell'oggetto" dietro un aggregato come sua attività. Questo è incapsulamento, giusto? Quindi per me una radice aggregata dovrebbe restituire solo DTO. I DTO sono spesso definiti nel livello di servizio, ma il mio approccio è quello di modellarlo nel dominio stesso. Il livello di servizio potrebbe ancora aggiungere un altro livello di astrazione, ma questa è una scelta diversa. E 'un buon consiglio?

5. I repository gestiscono tutte le operazioni CRUD al livello radice aggregato. Che dire di altre domande? Le query restituiscono gli oggetti DTO e non i domini. Affinché funzioni, il dipendente deve essere consapevole della struttura dati del dominio che introduce un accoppiamento. Il mio consiglio è simile a prima: usa gli eventi per popolare le visualizzazioni. Pertanto, la struttura interna non è resa pubblica, solo gli eventi portano i dati necessari per costruire la vista.

6. Unità di lavoro. Un controller al limite del sistema istanzia i comandi e li passa a un livello di servizio che a sua volta carica gli aggregati appropriati e inoltra i comandi. Il controller potrebbe utilizzare più comandi e passarli a più servizi. Tutto ciò è controllato dall'unità di modello di lavoro. Ciò significa, repository, entità, servizi: tutti partecipano alla stessa transazione. Sei d'accordo?

7. La logica di Buisness non è la logica del dominio.Da un punto di vista commerciale la realizzazione di un caso d'uso può comportare diversi passaggi: registrazione di un cliente, invio di un messaggio di posta elettronica, creazione di un account di archiviazione, ecc. Questo processo complessivo può essere impossibile in una radice aggregata del dominio. L'oggetto dominio dovrebbe avere accesso a tutti i tipi di infrastrutture. Soluzione: flussi di lavoro o saghe (o script di transazione). E 'un buon consiglio?

Grazie

Answer 1

Nonostante il mio commento di cui sopra, ho preso una pugnalata a tuoi punti. (nota: io non sono Eric Evans o Jimmy Nilsson quindi prendo il mio "consiglio" con un pizzico di sale).

1. Il vostro esempio "Considerate un oggetto che si raccomanda un partner per un sito di incontri.", Appartiene in un servizio di dominio (non un servizio di infrastruttura). Vedere questo articolo qui - http://lostechies.com/jimmybogard/2008/08/21/services-in-domain-driven-design/

2. Gli aggregati non accedono direttamente agli archivi, ma possono creare un'unità di lavoro che combina operazioni da più oggetti di dominio in uno.

3. Non sicuro su questo. Questa dovrebbe essere davvero una domanda da sola.

4. Questo è discutibile, in teoria, le entità di dominio non sarebbero direttamente disponibili al di fuori della radice aggregata, ma ciò non è sempre pratico. Considero questa decisione caso per caso.

5. Non so cosa intendi esattamente per "query". Se modellare tutti gli scenari di "lettura" possibili nel proprio dominio non sembra pratico o fornire prestazioni sufficienti, suggerisce che una soluzione CQRS è probabilmente la migliore.

6. Sì, sono d'accordo. UOW è uno strumento nella tua casella degli strumenti che puoi usare in vari livelli.

7. Questa affermazione è fondamentalmente errata "La logica aziendale non è la logica del dominio". Il dominio È la logica di rappresentazione aziendale, quindi una ragione per l'utilizzo di ubiquitous language.

Answer 2

La prima pratica migliore che posso suggerire è read the Evans' book. Twice.
Troppi "progetti DDD" non riescono perché gli sviluppatori fanno finta che DDD sia semplicemente OOP fatto bene.

Quindi, è necessario comprendere che DDD è destinato alle applicazioni che devono gestire regole aziendali molto complesse correttamente. In poche parole: se non hai bisogno di pagare un esperto di dominio per capire l'attività, non hai bisogno di DDD. Il concetto base di DDD, infatti, è lo ubiquitous language che sia i codificatori, sia gli esperti e gli utenti condividono per capirsi.

Inoltre, è necessario leggere e comprendere quali aggregati sono (limiti di coerenza) leggendo Effective Aggregate Design by Vernon.

Infine, è possibile trovare utile the modeling patterns documented here.