Architettura di cipolla: posizionamento a livello di logica aziendale

Question

Architettura di cipolla: posizionamento a livello di logica aziendale

#1 da (1 voti)
#2 da (1 voti)
#3 da (0 voti)

3

Dove dovrebbe essere collocata la logica di business per un progetto che utilizza Onion Architecture?

Nel mio caso, si tratta di un progetto basato su C #, che utilizza API Web e probabilmente un'interfaccia utente MVC per la presentazione. Ma potrebbe non avere importanza, dal momento che sono solo curioso di questo concettualmente.

I due diagrammi che seguono sembrano essere i più comuni che appaiono in tutto il web quando sono su Google le informazioni sull'architettura a cipolla:

Immaginiingrandite: diagramma 1 e diagramma 2

Se non mi sbaglio, qualsiasi cosa al di sotto dell'anello esterno è considerata il nucleo.

Nel Diagramma # 1 il più esterno del Core (anello blu) contiene interfacce di servizio, e mostra che l'anello esterno viola ha il logging, i servizi, ecc. Ciò significa che l'esterno anello viola contiene il livello di servizio e la logica aziendale?

In Diagramma n. 2 mostra Application and Domain Services come parte di Application Core (non solo le interfacce e il modello di dominio).

Sento che questi due diagrammi sembrano definire completamente diversi l'architettura di cipolla, ma tuttavia sembrano essere i due principalmente referenziati. O sto leggendo questo sbagliato?

Forse il risultato finale non è diverso, ed è solo questione di come sto guardando il layout del progetto nella mia testa, ma ho cercato di pensare al livello di servizio come parte del Infrastruttura sull'anello esterno. È un modo sbagliato di pensarci?

Le mie classi del livello di servizio possono avere repository o altre classi di servizi iniettate. I servizi stessi possono essere iniettati nei progetti del livello di presentazione (ad esempio un'API Web o un controller MVC) e da lì convertiti in un oggetto presentabile (DTO o ViewModel) tramite Automapper.

Grazie

c# architecture business-logic onion-architecture

posta Adam Plocher 01.07.2018 - 05:01

fonte

3 risposte

Leggi altre domande sui tag c# architecture business-logic onion-architecture

Riguardo agli interrupt e ai timer del sistema. Perché a volte i programmi vengono ancora eseguiti quando il sistema operativo richiede di terminare o continuare a funzionare? Come progettare un back-end di archiviazione per un foglio di calcolo cloud?

score 1 · Answer 1

Ciò che in genere si chiama "livello aziendale" su un'architettura a livelli può essere chiamato modello di dominio, ma non è questo il punto.

Dici che un anello contiene un altro ed è un errore concettuale: qualsiasi anello esterno comunica con il suo anello interno e possibilmente con il nucleo . Ovviamente l'UI non contiene la logica del dominio (poiché i test non contengono servizi applicativi).

Le differenze con un'architettura tradizionale a più livelli sono più fondamentali della forma che si usa per disegnare le dipendenze e in questo caso il nome (e la forma) memoizable non aiuta a cogliere la differenza fondamentale: il modello di dominio è la fonte centrale assoluta di verità per l'intero sistema. Nota la differenza di rottura: l'interfaccia utente utilizzerà il modello di dominio, non è limitato all'anello dei servizi di applicazione (nonostante ciò che le immagini potrebbero erroneamente indurre a pensare). Ciò non significa che esista una dipendenza diretta: interfacce e IoC sono sul posto per fornire l'astrazione e l'isolamento richiesti, il punto centrale non è isolare ogni anello ma isolare il modello di dominio da qualsiasi entità esterna .

score 1 · Answer 2

La logica aziendale è in realtà divisa in due tipi in uno dei due.

Data                                | Domain Entities      | Domain Model  
Data Business Logic                 | Repository Interface | Domain Service  
Software Environment Business Logic | Service Interface    | Application Service

Data Business Logic è la logica di business più pura e astratta. Qui cose come la tua età sono derivate dalla tua data di nascita e da un timestamp. Qui, solo le cose che avrebbero senso per un esperto di dominio possono esistere.

È consentito che Business Logic conosca più del dominio. Può riconoscere l'esistenza del software e fare alcune pulizie per quello. Ad esempio, puoi esprimere la tua età come un numero, in una lingua specifica, come% di una barra di avanzamento o come un'immagine di cartone animato con una lunga barba.

Onion Architecture non è l'unica a separare regole di business come questa. Vedete la stessa cosa in Clean Architecture ¹:

score 0 · Answer 3

La logica aziendale è il cerchio interno in entrambe le immagini (modello di dominio / entità di dominio). Questo se dove avviene l'elaborazione significativa, il resto è solo idraulico per far funzionare il sistema.

L'immagine a sinistra assume l'applicazione del pattern di repository, quindi la terminologia diversa (interfaccia repository vs servizio dominio). Fondamentalmente le immagini sono identiche.

La logica aziendale è un termine utilizzato per identificare un livello nella cosiddetta architettura a 3 livelli, che è un modello spesso utilizzato per i sistemi più vecchi che mancava della complessità aggiuntiva delle applicazioni Web e in genere ha un database relazionale in fondo / core. In 3 livelli hai presentazione, logica aziendale e archiviazione. Quest'ultimo livello viene ignorato come non interessante nelle immagini sopra, a fini di illustrazione architettonica non importa se si tratta di dati e / o comportamenti e di cosa il sistema alla fine fa.