Come strutturare un design guidato da domini in un'architettura di cipolle?

Panoramica

Facciamo un passo indietro e guardiamo all'originale Onion Architecture proposta da Jeffrey Palermo .

La skin esterna è l'interfaccia con il mondo esterno: l'interfaccia utente, la suite di test (l'idea è di promuovere TDD test sistematici allo stesso modo per ogni cosa all'interno) e l'infrastruttura.

Quindi scavare più a fondo all'interno del nucleo per trovare i servizi applicativi, servizi di dominio e oggetti di dominio (nel nucleo del nucleo).

Infrastrutture

L'infrastruttura ha un significato diverso qui che altrove. È infatti l'interfaccia verso il mondo esterno, e in particolare verso i servizi esterni, come i sistemi di gestione dei database o i servizi web esterni, il servizio di archiviazione locale o cloud, ecc.

Il termine "adattatore" è direttamente ispirato all'architettura esagonale di Cockburn: l'idea è che il lato interno dell'adattatore rimane invariato, ma la parte esterna può variare. Quindi, un giorno lavorerai con un adattatore Oracle che collega i tuoi servizi applicativi a un DBMS Oracle, il giorno dopo, potrai sviluppare un adattatore MongoDB per passare a Mongo come nuovo livello di persistenza.

Quindi la piattaforma e gli elementi specifici del sistema operativo dovrebbero essere nel livello infrastruttura. Se segui questa logica, tutto ciò che è nei circoli interni è neutrale rispetto alla piattaforma ("tecnologia neutra" può essere fuorviante).

Verso il nucleo

Qui hai un esempio di mappatura nell'architettura originale della cipolla:

• Gli oggetti di dominio (entità, oggetti valore, aggregati) sono nel nucleo
• Intorno al dominio, avrai i servizi di dominio (ad es. repository, servizi, ecc.)
• E ancora intorno a te ci sono i servizi applicativi, cioè i servizi a cui sono collegate l'interfaccia utente o altre interfacce.

Tuttavia, la variante di Wade Waldron è leggermente diversa per la parte interna :

• Il nucleo è costituito dalla creazione di blocchi di applicazioni che sono indipendenti dal dominio e utilizzati dal dominio. È come quelli offerti da una libreria standard. Personalmente, ho la sensazione che questa non sia una buona idea: quei costrutti di base non si adattano a questa struttura. Sono effettivamente usati dal prossimo anello, ma possono anche essere usati da qualsiasi altro anello, direttamente, anche senza passare attraverso il dominio. In effetti il nucleo dovrebbe essere ortogonale a questa architettura. In altre parole, è possibile utilizzare un elenco in qualsiasi punto dell'architettura, senza dover passare attraverso gli anelli successivi al nucleo.
• Ok, il dominio è chiaro, ma mette lì tutto ciò che è legato al dominio, tra cui: entità, oggetti valore, aggregati e anche repository, fabbriche e servizi di dominio. Quindi raggruppa gli oggetti dominio e i servizi di dominio del modello originale.
• Ok, l'API è ovvia: "corrisponde ai servizi applicativi nell'architettura originale, quelli che non sono accessibili direttamente, ma attraverso l'anello esterno.

Questo video spiega in dettaglio e con l'esempio la variante di Waldron dell'architettura di cipolla.

Per le persone che hanno la stessa domanda e ha ancora un po 'di confusione, questo potrebbe aiutarle.

1. Infrastruttura: come la definizione dice che una parte di Infrastruttura è un ponte tra le classi di dominio (costituita dalla logica correlata all'attività) e la relazione Database. e se stai usando ORM (come Hibernate Spring data e.t.c) l'implementazione è già presente. l'intera concezione riguarda il disaccoppiamento.

2.Core: Grazie alla risposta accettata ha già descritto splendidamente la parte centrale. Preferirei mettere oggetti di valore all'interno del nucleo, essendo detto che

Core is the building blocks not specific to any domain or technology, containing generic building blocks like lists, case classes, and actors.

punta verso oggetti valore e può essere di tipo personalizzato.