Livello applicazione vs livello dominio?

Sto leggendo Domain-Driven Design di Evans e sto discutendo l'architettura a strati. Ho appena realizzato che i livelli di applicazione e dominio sono diversi e dovrebbero essere separati. Nel progetto a cui sto lavorando, sono un po 'mescolati e non posso dire la differenza fino a quando non ho letto il libro (e non posso dire che ora mi sia molto chiaro), davvero.

Le mie domande, poiché entrambe riguardano la logica dell'applicazione e dovrebbero essere prive di aspetti tecnici e di presentazione, quali sono i vantaggi di tracciare un confine tra questi due?

Di recente ho letto DDD da solo. Quando sono arrivato a questa sezione sono stato piacevolmente sorpreso di scoprire che ho scoperto la stessa architettura a 4 strati che Evans ha fatto. Come sottolineato da @lonelybug, il livello del dominio dovrebbe essere completamente isolato dal resto del sistema. Tuttavia, qualcosa deve tradurre valori specifici dell'interfaccia utente (stringhe di query, dati POST, sessione, ecc.) In oggetti di dominio. È qui che entra in gioco il livello dell'applicazione. Il suo compito è tradurre avanti e indietro tra l'interfaccia utente, il livello dati e il dominio, nascondendo efficacemente il dominio dal resto del sistema.

Vedo molte applicazioni ASP.NET MVC in cui quasi tutta la logica è nei controller. Questo è un tentativo fallito di implementare la classica architettura a 3 livelli. I controller sono difficili da testare perché hanno così tante preoccupazioni specifiche dell'interfaccia utente. In effetti, scrivere un controller in modo che non riguardi direttamente i valori di "Contesto HTTP" è una vera sfida in sé e per sé. Idealmente, il controller dovrebbe semplicemente eseguire la traduzione, coordinare il lavoro e rispedire la risposta.

Può anche avere senso eseguire una convalida di base nel livello dell'applicazione. Va bene che il dominio presuma che i valori che vanno in esso abbiano senso (è un ID valido per questo cliente e questa stringa rappresenta una data / ora). Tuttavia, la convalida che coinvolge la logica aziendale (posso prenotare un biglietto aereo in passato?) Dovrebbe essere riservata al livello di dominio.

Martin Fowler in realtà commenta quanto siano piatti la maggior parte dei livelli di dominio in questi giorni . Anche se la maggior parte delle persone non sa nemmeno cosa sia un livello di applicazione, scopre che molte persone creano oggetti di dominio piuttosto stupidi e livelli di applicazione complessi che coordinano il lavoro dei diversi oggetti di dominio. Sono colpevole di questo me stesso. L'importante non è costruire un livello perché alcuni libri te lo hanno detto. L'idea è di identificare le responsabilità e separare il nostro codice in base a tali responsabilità. Nel mio caso, il tipo di "livello applicativo" si è evoluto naturalmente man mano che aumentavo i test unitari.

Prendendo spunto dai modelli di design aziendale di Martin Fowler, i livelli più comuni sono:

• Presentazione: si tratta di visualizzazioni, modelli di presentazione che generano l'interfaccia di interazione per l'applicazione (utilizzo l'interazione nel caso in cui l'applicazione acceda ad altri sistemi tramite servizi Web o RMI, pertanto potrebbe non essere un'interfaccia utente). Ciò include anche i controller che decidono come verranno eseguite le azioni e come.

• Dominio: è qui che risiedono le regole e la logica aziendale, i modelli di dominio definiti ecc

• Origine dati: questo è il livello di mappatura dei dati (ORM) e l'origine dati (database, file system ecc.)

Come si disegnano i confini tra i tre livelli:

• Non inserire una logica specifica di presentazione nei modelli o negli oggetti di dominio

• Non inserire la logica nelle pagine e nei controller, ovvero la logica per salvare oggetti nel database, creare connessioni al database, ecc., Il che renderà il tuo livello di presentazione fragile e difficile da testare

• Utilizzare un ORM che consente di disaccoppiare l'accesso all'origine dati e le azioni dal modello

• Segui il thin controller - paradigma del modello fat, i controller servono per controllare il processo di esecuzione non eseguendolo, più su http://www.littlehart.net/atthekeyboard/2007/04/27/fat-models-skinny-controllers/ e http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model modello, vista e controller,

Il livello di dominio modella il business della tua applicazione. Questa dovrebbe essere la tua chiara interpretazione delle sue regole, delle sue dinamiche dei componenti e contiene il suo stato in un dato momento.

Il livello dell'applicazione è "preoccupato" per la definizione dei lavori da svolgere per eseguire una determinata attività dell'applicazione. Principalmente, è responsabile del mandato del lavoro di dominio necessario e interagisce con altri servizi (esterni o meno).

Ad esempio , la mia applicazione software finanziaria ha un'operazione utente per modificare lo stato di un'entità modello (entità come definita in DDD [89]):

• "Il capo delle operazioni può approvare una proposta finanziaria".

Ma, come processo di candidatura, oltre a tutte le conseguenze modello di questa operazione, devo inviare una comunicazione interna ad altri utenti dell'applicazione. Questo tipo di lavoro è "orchestrato" nel livello dell'applicazione. Non vorrei che il mio livello di dominio pensasse di dirigere un servizio di messaggistica. (e certamente questa non è una responsabilità del livello di presentazione). In ogni caso, una cosa è certa: ho bisogno di un nuovo livello poiché il mio livello di dominio è interamente dedicato al core business e il mio livello di presentazione è tutto sull'interpretazione dei comandi dell'utente e sulla presentazione dei risultati.

Appunti:

• Business è una di quelle parole che spesso portano a molteplici interpretazioni del suo significato, ma di sicuro puoi trovare molti esempi e discussioni in DDD;
• DDD è l'acronimo di Domain-Driven Design book di Eric Evans e il numero tra parentesi quadre per il numero di pagina.

Il livello di dominio deve essere progettato come un livello di isolamento, il che significa che la logica aziendale e le regole non dovrebbero essere influenzate da eventuali modifiche ai codici (in Livello applicazione, Livello presentazione e Livello infrastruttura).

Si suppone che il livello applicazione sia progettato per fornire alcune funzioni su cosa può fare un'interfaccia di sistema (applicazione) (pensate che sia un'API o RESTful). Ad esempio, gli utenti possono accedere a un sistema e, in questa azione dell'applicazione (login), i codici del livello applicazione saranno i codici client per il livello dominio (o livello infrastruttura), in cui recupera l'oggetto dominio utente e applica i metodi di questo oggetto per implementare il funzione 'login'.

Il livello applicazione dovrebbe anche essere progettato come un livello di isolamento, il che significa che i comportamenti dell'applicazione non dovrebbero essere influenzati da eventuali modifiche ai codici (livello presentazione, livello dominio e livello infrastruttura).

Lo scopo della modellazione basata su dominio è quello di separare il modello di dominio essenziale e farlo esistere senza alcuna dipendenza da altri livelli e altri problemi di applicazione.

Ciò ti consente di concentrarti sul dominio stesso senza distrazioni (come il coordinamento tra l'interfaccia utente e i servizi di persistenza).

• Il livello applicazione e il livello dominio rientrano entrambi nell'ambito di attuazione.
• Il livello applicazione funziona come API.
• Il livello di dominio funge da implementazione dell'API, contiene la logica aziendale, quindi viene anche chiamato livello di logica aziendale.

La ragione principale di questi confini è la separazione delle preoccupazioni . Il codice che accede all'archivio dati dovrebbe preoccuparsi solo di accedere all'archivio dati. Non dovrebbe essere responsabile dell'applicazione delle regole sui dati. Inoltre, l'interfaccia utente dovrebbe essere responsabile dell'aggiornamento dei controlli nell'interfaccia utente, ottenere valori dall'input dell'utente e tradurli in qualcosa che il livello di dominio può utilizzare e nient'altro. Dovrebbe chiamare le operazioni fornite dal livello di dominio per eseguire tutte le azioni necessarie (ad esempio, salvare questo file). Un servizio Web chiamato dovrebbe essere responsabile della conversione dal supporto di trasmissione a qualcosa che il livello di dominio può usare e quindi chiamare il livello di dominio (la maggior parte degli strumenti fa molto di questo lavoro per te).

Questa separazione, se implementata correttamente, può offrire la possibilità di modificare parti del codice senza influire sugli altri. Ad esempio, forse l'ordinamento di una raccolta di oggetti restituita deve cambiare. Dato che sai che il livello responsabile della manipolazione dei dati (di solito il livello della logica aziendale) gestisce queste cose, puoi facilmente identificare dove il codice deve essere modificato. Oltre a non dover modificare il modo in cui viene recuperato dall'archivio dati o da qualsiasi applicazione che utilizza il dominio (l'interfaccia utente e il servizio Web dal mio esempio sopra).

L'obiettivo finale è rendere il codice il più semplice possibile da mantenere.

Come nota a margine, alcune cose non possono essere incorporate in un livello specifico del dominio (ad esempio, registrazione, convalida e autorizzazione). Questi elementi sono comunemente indicati come problemi trasversali e in alcuni casi possono essere trattati come un livello indipendente che tutti gli altri livelli possono vedere e utilizzare.

Personalmente penso che l'approccio a più livelli sia obsoleto e che l'approccio al servizio sia migliore. Hai ancora la linea netta disegnata nella sabbia su chi fa cosa, ma non ti obbliga a essere gerarchico. Ad esempio, un servizio di ordini di acquisto, un servizio di fatturazione e un servizio di spedizione, dal punto di vista dell'applicazione, tutti questi servizi rappresentano il tuo dominio e il differimento della responsabilità sopra descritto è ancora valido in questo contesto, è appena stato modificato che il tuo dominio esiste in più punti, utilizzando ulteriormente il concetto di separazione delle preoccupazioni.