Livello applicazione vs livello dominio?

Recentemente ho letto DDD da solo. Quando sono arrivato in questa sezione sono rimasto piacevolmente sorpreso di scoprire che ho scoperto la stessa architettura a 4 livelli 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 è di 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 controllori sono difficili da testare in quanto hanno così tanti problemi specifici dell'interfaccia utente. In effetti, scrivere un controller in modo che non sia direttamente interessato ai valori del "contesto Http" è una vera sfida in sé e per sé. Idealmente, il controllore dovrebbe semplicemente eseguire la traduzione, coordinare il lavoro e restituire la risposta.

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

In questo momento Martin Fowler commenta come gli strati di dominio più piatti sono 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 del dominio. Sono colpevole di questo anch'io. L'importante è non costruire uno strato perché alcuni libri ti hanno detto di farlo. L'idea è di identificare le responsabilità e separare il nostro codice in base a tali responsabilità. Nel mio caso, il "livello applicativo" si è evoluto naturalmente mentre aumentavo i test unitari.

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

• Presentazione: queste sono viste, modelli di presentazione che genera l'interfaccia di interazione per la tua applicazione (sto usando interazione nel caso in cui l'applicazione sia accessibile da altri sistemi tramite i servizi Web o RMI, quindi, potrebbe non essere un'interfaccia utente). Questo include anche i controller che decidono come verranno eseguite le azioni e come.

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

• Origine dati: si tratta del livello di mappatura dei dati (ORM) e dell'origine dati (database, file system, ecc.)

Come si disegna i confini tra i tre livelli:

• Non inserire la logica di presentazione specifica nei tuoi modelli o oggetti di dominio

• Non inserire la logica all'interno delle tue pagine e dei tuoi controller, cioè 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

• Utilizza un ORM che ti consente di disaccoppiare l'accesso e le azioni dell'origine dati dal modello

• Segui il controller sottile - paradigma del modello di grasso, i controller servono a controllare il processo di esecuzione che non lo esegue, più a link e link modello, vista e controller,

Il livello dominio modella la azienda della tua applicazione. Questa dovrebbe essere la tua chiara interpretazione delle sue regole, è la dinamica delle componenti e contiene il suo stato in ogni dato momento.

Il livello di applicazione è "preoccupato per" definire i lavori necessari per eseguire una determinata attività dell'applicazione. Principalmente, è responsabile del mandato il lavoro necessario del dominio e interagisce con altri servizi (esterni o non).

Per 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 applicazione, oltre a tutte le conseguenze del 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 a 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 in quanto il mio livello di dominio è tutto incentrato sul core business e il mio livello di presentazione riguarda l'interpretazione dei comandi dell'utente e la presentazione dei risultati.

Note:

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

Il livello di dominio dovrebbe essere progettato come un livello di isolamento, il che significa che la logica e le regole di business non dovrebbero essere influenzate da eventuali codici (in Application Layer, Presentation Layer e Infrastructure Layer).

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

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

Il punto di Domain Driven Modeling consiste nel separare il modello di dominio essenziale e farlo esistere senza alcuna dipendenza da altri livelli e altri problemi applicativi.

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

La ragione principale di questi limiti è separazione dei dubbi . Il codice che accede all'archivio dati deve solo preoccuparsi dell'accesso 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, ottenendo i valori dall'input dell'utente e traducendoli in qualcosa che il livello del dominio può utilizzare, e nient'altro. Dovrebbe chiamare le operazioni fornite dal livello del dominio per eseguire tutte le azioni necessarie (ad esempio, salvare questo file). Un servizio web che viene chiamato dovrebbe essere responsabile della conversione dal mezzo di trasmissione a qualcosa che il livello del dominio può usare, e quindi chiamare il livello del dominio (la maggior parte degli strumenti fa un sacco di questo lavoro per te).

Questa separazione, se implementata correttamente, ti può permettere di modificare parti del tuo codice senza influire sugli altri. Ad esempio, forse l'ordinamento di una raccolta restituita di oggetti deve essere modificato. Poiché sai che il livello responsabile della manipolazione dei dati (in genere il livello della logica aziendale) gestisce questa roba, 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 del mio esempio precedente).

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

Come nota a margine, alcune cose non possono essere incasellate in un livello specifico del dominio (ad esempio registrazione, convalida e autorizzazione). Questi elementi vengono comunemente chiamati preoccupazioni trasversali e in alcuni casi possono essere trattati come un livello che si trova da solo e che tutti gli altri livelli possono vedere e utilizzare.

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

• Livello applicazione e Livello dominio entrambi rientrano nell'ambito di applicazione.
• Livello applicazione funge da API.
• Livello di dominio funge da implementazione dell'API, contiene logica di business, quindi chiama anche Livello di logica di business .