Repository di packaging e loro interfacce in DDD

Question

Nelle applicazioni successive al DDD su cui ho lavorato, tendiamo ad avere un Service Layer che contiene i Servizi + Repository + le interfacce per repository e servizi, tutti vivono nello stesso assembly, mentre il dominio il modello vivrà in un'assemblea diversa. Sembra che tutto ciò che non si adatta al modello di dominio sia ingombrante in questo grande progetto.

In un'applicazione che segue i principi e i modelli del DDD, come si impacchettano i repository e le interfacce che implementano? Quali sono le migliori pratiche per l'imballaggio di diverse parti logiche dell'applicazione DDD (o dell'imballaggio in generale per quella materia)? Ogni partizione logica dovrebbe vivere nel proprio assieme? Ha importanza?

Answer 1

Vorrei esaminare l'architettura di cipolla. Fondamentalmente tutti i modelli di dominio e le interfacce per i servizi di dominio sono considerati core. I livelli dipendono solo dai livelli sopra di loro che sono più vicini al nucleo. La loro effettiva implementazione è gestita dall'infrastruttura.

Vedi qui http://jeffreypalermo.com/blog/the-onion-architecture-part-1/

In definitiva le interfacce sono ciò che definisce l'applicazione. La logica di come viene implementata viene esternalizzata. Quindi mi aspetto che tu abbia degli assembly con Domain Models e Domain Services, un front end (ad es. MVC ecc.) E un assembly di infrastruttura che implementa cose come NHibernate per fornire dati, ecc.

Puoi vedere vari esempi che implementano l'architettura nelle varie parti dell'articolo collegato. Il più semplice è qui https://bitbucket.org/jeffreypalermo/onion-architecture/get/1df2608bc383.zip

Potete vedere le questioni relative alla qui https://stackoverflow.com/questions/tagged/onion-architecture

Il vantaggio principale è che è in gran parte le preoccupazioni infrastrutturali che cambieranno il più delle volte. Nuove tecnologie a livello di dati, nuova archiviazione di file, ecc. Anche il dominio principale dovrebbe essere ragionevolmente stabile in quanto non implementa nulla solo definendo per contratto (interfacce) ciò che richiede. Mettendo i problemi di implementazione in una posizione, si riduce al minimo la quantità di modifiche che saranno richieste agli assembly.

Answer 2

È possibile trovare le linee guida per la progettazione dei livelli in DDD book. Hai fondamentalmente ottenuto:

• Domain
• Infrastrutture
• Applicazione
• UI

servizi sono disponibili in 3 tipi: Application service layer, servizio strato di infrastrutture e di servizi strato di dominio, a seconda su cosa fa il servizio. Per quanto riguarda i Repository, i loro contratti (interfacce) risiedono spesso nel Dominio mentre le loro implementazioni concrete sono nel livello Infrastructure.

Per quanto riguarda gli assiemi, consiglierei almeno uno per strato. Assemblee e dll sono tutte basate sulla riusabilità, sulla separazione delle preoccupazioni e sul disaccoppiamento - potrò scegliere quella dll e rilasciarla per riutilizzarla in un'altra applicazione? Sarò in grado di farlo senza trascinare una serie di funzionalità non correlate che porteranno complessità inutili a quell'altra applicazione? Sarò in grado di sostituire facilmente la mia DLL per un'altra semplicemente cambiando una riga di codice nel mio modulo di iniezione delle dipendenze? e così via.