Domain Layer should only contain Business Logic. This confuses me when I read about the Onion architecture, which states that the domain layer should contain all interfaces including services and repositories

La logica aziendale è la responsabilità principale del livello dominio. Tuttavia, se questo fosse strettamente pertinente a tutto lo strato del dominio, non sarebbe in grado di comunicare con qualcos'altro.

Ciò che ti viene proibito di inserire nel livello del dominio è la conoscenza del volatile, concreto, è ciò che utilizziamo oggi, i dettagli di NHibernate, o il web, il database, il file system o qualsiasi altra cosa altrimenti vogliono usare domani.

Il dominio dovrebbe comunicare utilizzando qualsiasi cosa conveniente da usare, una struttura dati, un oggetto, una collezione. Non dovrebbe essere il lancio di set di risultati, json, tavoli di fila o qualsiasi altra cosa che dia via ciò che sta parlando.

Il che significa che è necessario tradurre set di risultati, json, ecc in, o da, quelli comodi da usare in un livello esterno al dominio. Questo fa parte dell'infrastruttura. Questa è la parte dell'adattatore delle porte e degli adattatori in Hexagonal Architecture che onestamente non è poi così diverso da Onion Architecture o Pulisci architettura .

Le interfacce / le astrazioni necessarie per comunicare con quell'infrastruttura, o far dialogare quell'infrastruttura con il dominio, sono ciò che il dominio conoscerà. Il dominio li possiederà e imporrà quando e se potranno cambiare. Nient'altro può dire il modo in cui cambiano.

Questo è ciò che "rimuove tutta la conoscenza" di quei dettagli esterni, ma consente comunque la comunicazione.

Per prima cosa, l'architettura DDD e cipolla sono cose diverse che puoi usare l'una senza l'altra. Uso quasi sempre cipolle, ma quasi mai DDD ... è solo eccessivo per la maggior parte delle cose a mio parere (e l'opinione del suo creatore). Inoltre, ritengo che siano altre tecniche che possono essere utilizzate al posto di DDD, anche in situazioni in cui è utile.

Il nucleo della tua cipolla (non DDD) è il tuo progetto di dominio. Questo contiene oggetti business. Modellano il funzionamento concettuale della tua applicazione, senza riguardo per i dettagli di implementazione come la persistenza o l'interfaccia utente. Non ci sono riferimenti al database, o anche classi che gestiscono il database !

Supponiamo che la tua applicazione sia un'applicazione fiscale proprietaria. Il nucleo della tua cipolla, gli oggetti business, avrebbe classi come: IncomeEntry , ExpenseEntry , Building , Employee , TaxCalculator , ect. Si farebbero riferimento l'uno all'altro, ma mai nulla a che fare con l'interfaccia utente o il DB.

Il prossimo livello della cipolla, infrastruttura, avrebbe i tuoi repository da salvare e richiamare. Questo progetto farà riferimento ai tuoi oggetti di dominio. Il tuo IncomeEntryRepository avrà metodi come GetIncomeEntries che restituiscono IncomeEntry oggetti.

Successivamente, hai il tuo progetto UI all'esterno della cipolla. Può utilizzare sia gli oggetti business che i repository per mostrare informazioni utili all'utente.

Tutti sono stati contenti della tua interfaccia utente rapida ed efficiente, ma ora i livelli C vengono da te e ti chiedono di creare un'API per alcune delle filiali. Non vogliono sfruttare la potenza della tua applicazione, ma i codici legali significano che non possono avere accesso ai tuoi dati. Questo è dove il potere della cipolla.

Semplicemente, sul bordo esterno della cipolla, aggiungere un'API Web che consenta alle filiali di inserire i propri dati ed eseguire calcoli fiscali su di essi. Questo web API dovrà solo fare riferimento al dominio del dominio

Therefore should the domain layer contain domain logic only?

Risposta breve

No.

Risposta media

Il modulo domini (il livello è idiomatico per uno stile particolare) contiene anche le descrizioni dei servizi richiesti per eseguire la logica del dominio.

Risposta lunga

Un punto di partenza per comprendere i limiti del modello di dominio è quello di esaminare esempio di implementazione dell'esempio di routing del carico . pagina del progetto originale afferma

This project is a joint effort by Eric Evans' company Domain Language and the Swedish software consulting company Citerus.

Se osservi il codice del dominio, vedrai che la maggior parte dei riferimenti ai pacchetti punta ad altri componenti all'interno del pacchetto del dominio. Questo è coerente con l'idea del design della cipolla; il modulo di dominio si trova nel core, senza dipendenze da altri componenti.

Ma se guardi attentamente repository , potresti notare che sono interfacce ; in particolare, stanno descrivendo un contratto senza fornire un'implementazione. L'implementazione effettiva (usando Hibernate) è modulo infrastruttura .

In altre parole, l'infrastruttura fornisce un servizio definito dal modello. Se pensi a porte e adattatori: il modulo di dominio ha definito la porta e il modulo dell'infrastruttura fornisce un adattatore che si collega alla Hibernate api.

Il servizio di routing è fatto allo stesso modo; l'interfaccia è descritta nel modulo dominio , l'implementazione effettiva è terminata in infrastrutture .

Se guardiamo solo alle frecce di dipendenza, abbiamo un modello di dominio che non sa nulla dell'infrastruttura, e abbiamo Hibernate che non sa nulla del dominio, e abbiamo un componente di infrastruttura che dipende da Hibernate e il dominio per fungere da ponte tra i due.

Evans stava scrivendo nel 2003, e usando Java; in altre parole, stava lavorando da un kit di strumenti più limitato di quello che abbiamo oggi. È possibile ulteriormente mettere a nudo l'espressione del comportamento del dominio dalle specifiche rappresentazioni di stato di in memoria , nello stesso modo in cui il repository isola il comportamento del dominio da persistito rappresentazioni di stato. In questo modo puoi ridurre il nucleo del dominio a un sacco di interfacce dati e alcune funzioni che descrivono i comportamenti del dominio in vari casi d'uso.

Devo ancora provare che tale separazione è economicamente vantaggiosa; nei modelli di dati di memoria non sembrano cambiare indipendentemente dal modello abbastanza spesso da giustificare il lavoro extra.