DDD, modularizzando i layer applicazione e dominio senza rompere il DIP

Question

DDD, modularizzando i layer applicazione e dominio senza rompere il DIP

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

5

The application layer is thin in terms of domain logic - it merely coordinates the domain layer objects to perform the actual work.

Quando si parla di modularizzazione e supponendo che il modulo che contiene le entità di dominio e le interfacce dei servizi di dominio appartenga al livello del dominio, il livello dell'applicazione dipende dal livello del dominio, che interrompe principio dell'inversione di dipendenza .

The implementation of the high-level component's interface by the low level component requires that the low-level component package depend upon the high-level component for compilation, thus inverting the conventional dependency relationship.

Cosa mi manca?

Aggiungo un diagramma UML per chiarire il problema che vedo.

Il livello di persistenza dipende da un'astrazione nel livello di dominio - > DIP ok!
Il livello di applicazione dipende da un'astrazione nel livello di dominio - > Questo rompe il DIP?

domain-driven-design solid patterns-and-practices layers architectural-patterns

posta diegomtassis 17.11.2014 - 12:43

fonte

3 risposte

Leggi altre domande sui tag domain-driven-design solid patterns-and-practices layers architectural-patterns

Come implementare la crittografia lato client semplice e sicura Unit of Work Concurrency, come viene gestito

score 3 · Answer 1

Non infrange il DIP perché il Dominio è il livello più alto, più alto di quello dell'applicazione e non ha una dipendenza da esso. Il contrario (Dominio in base all'applicazione) interromperà DIP.

[Modifica: chiarimento] Inoltre, la parte "dovrebbe dipendere dall'astrazione" di DIP non si applica necessariamente qui, perché le entità di dominio non possono essere astratte: sono già un modello concettuale puro del tuo dominio. L'unica eccezione potrebbe essere Servizi di dominio, perché potresti mettere un'interfaccia davanti a quelli.

Come nota a margine, in genere non è necessario sfruttare l'inversione di dipendenza all'interno del modello di dominio stesso, perché

Le entità di dominio hanno pochi o nessun collaboratore
Quelli che hanno sono ben identificati (linguaggio ubiquo) e spesso non di natura polimorfa
Il dominio risiede interamente nella memoria senza alcuna comunicazione esterna (framework di party 3D, rete, disco, ecc.), quindi può essere testato con test di integrazione rapidi senza bisogno di mock.

score 1 · Answer 2

Il principio di inversione delle dipendenze ha un'eccezione principale: ad un certo punto devi fare qualcosa di concreto. Un esempio è in ordine.

Diciamo che hai un'applicazione di blog. Hai due tabelle nel database e due modelli di dominio, ad esempio Blog e Post . Diciamo anche che stai lavorando con un framework MVC come ASP.NET MVC, Ruby on Rails, ecc.

Ora, supponiamo che tu abbia un'altra classe chiamata BlogPostsController che implementa le operazioni CRUD di base per i post del blog.

Il framework implementa il principio di inversione della dipendenza non codificando con difficoltà le seguenti righe ovunque nella sua base di codice:

new BlogPostsController();

Il framework esamina l'URL in entrata e costruisce il nome della classe controller in modo dinamico. Il framework non ha una strong dipendenza dalla tua classe BlogPostsController .

Ora, diamo un'occhiata al controller. All'interno del tuo controller vedi new Post() pepato dappertutto. Questa è non una violazione del principio di inversione delle dipendenze perché a un certo punto tu, come programmatore, hai bisogno di salvare effettivamente un post sul blog nel database.

Il principio di inversione delle dipendenze si rivolge principalmente a dipendenze che non sono focalizzate al laser sull'intenzione di base di una classe, ad esempio creando un nuovo "controller" in un framework MVC. Per non farlo, non vuoi un'istruzione% cod_de% o switch codificata. L'autenticazione è un'altra area in cui DIP è importante perché la classe if non deve preoccuparsi della gestione dei cookie del browser o se l'utente accede utilizzando una pagina di accesso personalizzata cablata a un database o utilizzando l'autenticazione di Windows o l'autenticazione di testo normale nel browser collegato a LDAP dietro le quinte.

score 1 · Answer 3

Il DI significa che il tuo livello di applicazione non deve dipendere direttamente dalle classi del servizio di dominio, ma su interfacce astratte di tali classi di servizio (in realtà, il tuo diagramma lo sta già mostrando). L'unica cosa che è discutibile è se queste interfacce dovrebbero essere collocate nel livello di dominio. È meglio posizionarli all'esterno, in un livello "Interfaccia di servizio", in modo che possano essere referenziati dal livello Applicazione e dal livello Dominio. In questo modo, non hai dipendenze dirette tra il livello applicazione e il livello dominio, in nessuna delle due direzioni possibili.

Naturalmente, come Greg ha già sottolineato, da qualche parte nella tua applicazione devi collegare tutto insieme e creare effettivamente istanze non astratte delle tue classi di servizio del dominio. O si utilizza un framework DI per questo scopo, oppure lo si fa manualmente in una sorta di parte "infrastruttura" del programma, al di fuori di uno qualsiasi dei "layer" classici. Né un framework DI, né un'infrastruttura di avvio manuale sono rilevanti ai sensi del DIP.