Design basato su domini in rete - Struttura del progetto

Question

Design basato su domini in rete - Struttura del progetto

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

2

Sto prendendo in considerazione DDD e come creare una struttura di progetto C # per una WebApp Core .Net. Ho cercato un po 'per il web, ad esempio Come strutturare un design guidato da dominio in un'architettura di Onion? , link e diversi corsi di Pluralsight.

Ciò che mi infastidisce è il fatto che questi esempi di HelloWorld non sembrano funzionare molto bene nella vita reale: Supponiamo di creare la struttura di cipolla propagata di Applicazione, Dominio e Infrastruttura. In tal caso, l'applicazione sarà la parte WebApi, il dominio i servizi di dominio, le entità, gli oggetti valore ecc. E l'infrastruttura l'implementazione delle interfacce definite nell'assembly del dominio.

Fin qui tutto bene, ma con questo approccio, dovrei definire ogni bit del codice di aiuto nel Domain-Layer. Per servizi, gestori, ecc. Potrei definire solo le interfacce e lasciare che l'implementazione si inietti dal livello infrastruttura. Ma non appena ho iniziato a programmare in questo modo, avevo cartelle come Attributi, Gestori (servizi di basso livello per REST, File ecc.) E una tonnellata di altre cose tecniche nel mio livello di dominio. Per motivi di test, ho provato a ripristinare la dipendenza, quindi il dominio ha come obiettivo l'infrastruttura. Ciò consente di spostare tutto il codice di supporto e i gestori di basso livello sull'infrastruttura, ma rende la comunicazione scomoda: poiché le entità e gli oggetti valore sono ancora nel dominio, l'infrastruttura non li conosce più, quindi dovrei mappare a DTO, aggiungendo un altro livello di mappatura solo per questa comunicazione.

Leggendo il libro di Eric Evans, ho preso l'idea che il Domain-Layer dovrebbe essere scritto in un linguaggio onnipresente, essere agnostico tecnico ed essere la piattaforma di comunicazione con gli esperti del dominio. Ma non riesco a trovare una buona soluzione per avere entrambi i mondi migliori. Mi sto perdendo qualcosa di cruciale qui?

c# domain-driven-design projects-and-solutions

posta Matthias Müller 26.07.2017 - 21:00

fonte

3 risposte

Leggi altre domande sui tag c# domain-driven-design projects-and-solutions

Architettura ad alta scala che utilizza l'event sourcing e la coerenza finale Memoria / presentazione UUID MySQL

score 2 · Answer 1

Penso che spesso ci pensiamo troppo quando stiamo cercando di imparare un nuovo modo di fare le cose. Invece di far bollire il problema fino alla cosa più piccola che possa funzionare, pensiamo a cose che non sono importanti in questo momento. L'architettura di cipolle e DDD lavorano insieme per fornire un modo per permetterti di definire il modo più semplice di fare le cose.

Qual è il tuo dominio?

Questa è la domanda che devi porci. I concetti principali sono:

Come gli oggetti di dominio interagiscono con altri oggetti di dominio
Come gli oggetti di dominio interagiscono con i servizi primari

Tutto il resto è completamente fuori dal dominio. Se si utilizza un modello di repository per la persistenza o qualcos'altro è vicino al punto. Ci saranno punti in cui il tuo oggetto dominio deve interagire con un servizio. Va bene.

Stub i tuoi servizi utilizzando interfacce e terminologia di dominio

E fermati. Puoi avere un design completamente gestito da domini con questi due concetti.

Servizi dall'interno verso l'esterno

In un'architettura di Onion, l'implementazione dei tuoi servizi viene eseguita a un livello esterno al tuo modello di dominio. Ciò mantiene il dominio pulito e separato dalle preoccupazioni del tuo servizio.

Un esempio potrebbe utilizzare un database SQL per la persistenza. Se è necessario modificarlo in futuro o aggiungere altri tipi di database (grafico, ricerca, ecc.) Per facilitare il sistema, è possibile localizzare tali modifiche dietro il servizio definito nel modello di dominio.

Cose comuni che non sono centrali nel dominio:

Autenticazione
Persistenza
Rendering (ovvero servizi REST, applicazione Web completa, app desktop, ecc.)
Internazionalizzazione
Messaggi

Questo non è un elenco completo ed esauriente.

Il tuo dominio potrebbe avere utenti e quegli utenti hanno ruoli ... ma come l'utente è autenticato e quei ruoli forniti sono cose che cambieranno nel tempo.

Le modalità di messaggistica possono cambiare nel tempo, oltre a contenuti specifici, ma i tipi di messaggi e trigger che li attivano sono correlati al dominio.

Sentiti libero di applicare gli stessi concetti per implementare i tuoi servizi come hai fatto per il dominio principale. L'unica differenza è che il dominio per un servizio di persistenza è diverso rispetto all'applicazione principale.

Struttura del progetto

Dipende davvero da quanto granulare si vuole andare, ma per lo meno si dovrebbe avere una libreria come modello di dominio principale. Puoi avere implementazioni di servizi in progetti separati o raggruppare alcune cose insieme.

+ Solution
  + Project.Domain (or Core if you prefer)
  + Project.Domain.Test
  + Project.Persistence.Service
  -- etc.
  * WebAPI

Non essere eccessivamente religioso riguardo alla tua organizzazione di progetto. Deve solo essere ragionevolmente chiaro dove cercare le cose. La tua libreria di dominio principale ha gli oggetti di dominio e le interfacce per i servizi, se necessario. L'unica regola che raccomanderei è di avere una chiara gerarchia delle dipendenze del progetto. Project.Domain non dovrebbe dipendere da nulla al di fuori della tua libreria standard per la lingua che stai utilizzando.

score 0 · Answer 2

Hai familiarità con le porte e gli adattatori? Penso che potrebbe aiutarti a risolvere le dipendenze. Questo articolo è un buon punto di partenza.

link

È importante conoscere la distinzione tra porte e adattatori primari e secondari se si desidera applicare questo modello con successo.

I link in fondo all'articolo sono da leggere.

score 0 · Answer 3

Le interfacce sono dichiarati nello strato di dominio quando hanno bisogno di essere utilizzato dal dominio. Dal tuo secondo link :

Put your infrastructure interfaces in to Domain Model Layer. Your domain will use them to get data, it doesn't need to care how, it just knows there is an interface exposed and it will use it.

Dove mi sembra di dissentire con l'autore è: non tutti gli oggetti di infrastruttura saranno come questo. Solitamente ho molti servizi di infrastruttura utilizzati solo dal livello Applicazione e non definisco le loro interfacce nel dominio.