Quali sono i livelli tipici in un'architettura a cipolla?

Question

Attualmente sto studiando il design guidato dal dominio e provo ad applicarlo per un progetto WPF. Ho guardato alcuni video tutorial, e letto molti articoli, come:

• Onion archicecture dependencies in the same layer: Infrastructure and Web communicating
• http://eohmicrosoft.blogspot.fr/2012/08/laying-it-out-onion-architecture.html
• Domain Driven Design: Domain Service, Application Service

ho capito il focus su interfacce e inversione del controllo. Ho letto che c'erano alcuni nomi di layer ricorrenti (dominio/core per la rappresentazione della sfera della conoscenza, infrastrutture per la persistenza, applicazione per ... non capisco), ma cambiano, a seconda degli articoli che ho letto. Alcuni addirittura non appaiono.

Sarebbe possibile avere un elenco di tutti i livelli che, in teoria, sono richiesti in un'architettura a cipolla per affrontare tutti i bisogni e problemi, con il loro intento (che tipo di codice contengono, che tipo di necessità fare cercano di soddisfare, a quale livello hanno bisogno di fare riferimento), per favore?

Answer 1

Totalmente d'accordo con la risposta di Hippoom. È perfetto per iniziare da lì.

Ora,

ho letto ci sono stati alcuni nomi dei livelli ricorrenti (dominio/core per la rappresentazione della sfera della conoscenza, infrastrutture per persistenza, domanda di ... non capisco) , ma cambiano, a seconda degli articoli che ho letto. Alcuni addirittura non appaiono.

Sì, la decisione sui livelli in un'applicazione dipende da molti fattori in uno scenario particolare. È come le università dividono i loro programmi e fanno curriculum. Dipende dalla capacità/diversità che vogliono servire, dalla necessità e dallo scopo dell'università. È molto diverso nei dettagli (denominazione e partizioni) in tutto il mondo, ma il nucleo e l'intento sono sempre gli stessi.

Allo stesso modo, i livelli di un'applicazione dipendono dalla necessità e dall'ambito. A volte gli architetti definivano il nome dei livelli secondo la loro filosofia e convenzione seguiti nell'organizzazione. Quindi a volte l'intento e il nome possono differire in una certa misura. Ma l'idea del codice di avere a disposizione, manutenibile e adempiere allo functional and non-functional requirements in mano, rimane sempre la stessa.

sarebbe possibile avere un elenco di tutti i livelli che, in teoria, sono tenuti in un'architettura cipolla far fronte a tutte le esigenze e problemi, con loro intento (che tipo di codice se essi contengono, cosa tipo di dobbiamo fare cercano di compiere, quale livello hanno bisogno di fare riferimento a), per favore?

Hippoom lo ha fatto molto bene e ha descritto anche l'intento nello scatto.
livelli standard sono descritte qui: http://jeffreypalermo.com/blog/the-onion-architecture-part-1/
Come ho già detto strati possono differire secondo le applicazioni hanno bisogno.

Spero che vi aiutano. Grazie.

dettagli inclusi come da primo commento di David di seguito:

servizi applicativi implementare i casi d'uso ed effettuare chiamate ai Servizi di dominio e entità del dominio in infrastrutture e servizi, al fine di ottenere il lavoro fatto. Fornisce interfacce al mondo esterno (principalmente progetti di livelli dell'interfaccia utente) per realizzare determinate funzionalità. Ad esempio, UserService è un servizio di applicazione. UserService può fornire funzionalità per verificare l'autenticazione per l'utente e l'autorizzazione per la particolare risorsa, modifica di privilegio per un utente da admin, escludere l'utente ecc Per raggiungere questi casi d'uso, sarebbe utilizzare UserRepository e UserEntity da strati inferiori.

I servizi di dominio sono indipendenti dall'applicazione; forniscono un mezzo per garantire l'integrità del modello di dominio incapsulando le operazioni CRUD (Crea, Leggi, Aggiorna, Elimina) e l'accesso ai dati. Di solito hanno repository di oggetti Dominio e implementazione UoW in Onion Architecture.

Answer 2

Solo qualche esperienza personale, io uso questa architettura di cui Eric Anche DDD libro:

In breve:

1) Interfacce è costituiti da componenti che sono responsabili per l'interazione con l'utente (un vero e proprio punto finale utente o una macchina remota), controller web mvc, oggetto vista Web, ad esempio facciata remota.

2) L'applicazione definisce le funzionalità fornite dal sistema. Penso che sia molto accoppiato con il livello Interfaces. Se si definisce un metodo in Applicazione, spesso è necessario aggiungere anche una classe/metodo Interfaces. Ma diverse classi/metodi di interfacce possono dipendere dallo stesso oggetto Application, ad esempio si fornisce sia un Web Ui sia un servizio Web per l'ordine del posto.

3) Dominio, la parte più stabile del sistema. Ad esempio, nel contesto linguistico, parola/frase sono oggetti Dominio che hanno il loro significato, li ho organizzati per formare questa risposta. Quindi potresti considerare me come un oggetto Application anche se non buono perché non parlo fluentemente l'inglese: P

4) Infrostruttura, in realtà non penso che questo sia uno strato, implementa tutti i tre precedenti . Ad esempio, hai un'interfaccia OrderRepository nel tuo livello di dominio e potresti implementarla utilizzando un framework orm (infrastruttura di persistenza). La maggior parte dei miei oggetti infrastruttura sono adattatori (implementa un'interfaccia nel livello Applicazione/Dominio/Interfacce e si adattano a componenti esterni come database, provider di messaggi, server di posta elettronica e così via).

Spero che questo aiuti.

Aggiornamento per intento infrastrutture:

Questo è uno di vista pacchetto del nostro progetto.

ci sono alcuni adattatori a livello di infrastruttura:

1.infrastructure.channel.XXX ogni pacchetto contiene diversi adattatori a un particolare fornitore di pagamento online.

2.infrastructure.payment contiene adattatori per un sistema di pagamento della nostra organizzazione ma si trova in un altro contesto limitato. Usiamo MakePaymentService (un servizio di dominio) per disaccoppiare il sistema di pagamento da un'altra parte di questo sistema.

3.infrastructure.messaging contiene gli adattatori per provider di messaggistica, forniamo un JMS implementare per PaymentWasMadeNotifier (un servizio applicativo)

4.infrastructure.persistence contiene gli adattatori per banca dati, mettiamo a disposizione un iBATIS (un quadro ORM in Java) per i repository di dominio.

Questi adattatori sopra tutti implementano alcune interfacce in livelli Application/Domain. Di seguito alcune "servizio", ma sono generiche:

5.infrastructure.mail

6.infrastructure.logging

7.infrastructure.security

Questi pacchetto di cui sopra espone alcune interfaccia e implementazioni. Ad esempio, forniamo un'interfaccia MailManager, è agnositico a particolari caratteristiche. L'oggetto, il contenuto è a livello di applicazione/livello dominio. Forniamo un'implementazione usando javamail nello stesso pacchetto.

public interface MailManager { 
void send(String subject, String content); 
} 

8.infrastructure.time questo è speciale, abbiamo qualche lavoro cron in questo sistema, in modo da introdurre un orologio per disaccoppiare il tempo da lavoro e quindi la sua impostazione amichevole per i test (Provate a immaginare che abbiamo un lavoro, dovrebbe essere lanciato il 25, ogni mese, possiamo testare il lavoro impostando il tempo corrente al 25, anche se è il 1 ° oggi). Forniamo un'implementazione nel pacchetto di persistenza (per alcuni motivi, abbiamo bisogno di usare il database' ora in produzione)

public interface Clock {  
    Date now(); 
} 

Quindi la mia comprensione è: infrastruttura fornisce servizi/implementazioni per gli altri tre strati, ma sono tecnologia specifica . Ad esempio, Oggetto, contenuto, da, a, cc sono modelli di dominio nel contesto di invio, ma sono infrastrutture nel contesto del dominio. Il livello infrastruttura li separa per te.