Nell'architettura a livelli con ddd

3

Ho lavorato su un'architettura, cercando di saperne di più su DDD, architettura a strati, ecc.

Ecco cosa ho:

Dominio
Qui ho le mie entità, le classi che si mappano direttamente a una tabella di database. Dispongo di un'infrra in cui dichiaro le enumerazioni utilizzate dalle entità, il mio UserManager e ClaimManager e alcune attestazioni, come StaffClaim . L'ultima cosa che ho messo qui è l'interfaccia per i repository, come IStaffRepository.

Prima domanda qui : è questo il posto giusto per mettere le mie affermazioni, i ruoli e i manager? Sento che questo è giusto per le affermazioni e i ruoli perché fanno parte di ciò che ho imparato a comprendere come dominio. Tuttavia, ritengo strano mettere i gestori usati dai repository qui.

Spostamento sul DAL.
DAL Qui ho le configurazioni delle mie entità, come relazioni, restrizioni sulle colonne, indici di database, ecc. In questo livello ho creato le implementazioni concrete dei repository, il contesto daatabase e un'interfaccia che apre il DAL per la comunicazione che chiamo IUnitOfWork.

In corso ...
Servizi
Qui ho solo l'implementazione concreta di IUnitOfWork esposto dal DAL.
Questa classe espone le interfacce dei repository e alcuni altri metodi, come OpenDbConnection e StartTransaction .

Successivamente, ho creato un progetto MVC come interfaccia utente.
UI
Qui ho i miei punti di vista, viewmodels, controller e API.

Seconda domanda Quindi, da un controller, posso fare questo genere di cose: unitofwork.Staffs.GetById() .
Ora, questo è il posto dove mi sono perso.
Ho bisogno di restituire le entità mezzo cotto dal repository, userò query come questa molto :

from s in set
where <condition>
select new { Id = s.Id, Name = s.Name }

Questo crea un tipo anonimo, che non può essere restituito dal repository. Ho bisogno di una classe per rappresentare questa entità incompleta. Dove devo collocare questo tipo di classi? Avrò bisogno di molte, molte di queste classi. Non sembra giusto metterli nel dominio, e non sembra giusto metterli nel servizio, dove è il mio UnitOfWork, perché allora avrò il mio DAL che fa riferimento al mio servizio.

    
posta victor 17.09.2018 - 17:32
fonte

1 risposta

1

A partire dal tuo dominio. Le classi Manager -type generalmente non rappresentano un oggetto dominio, ma sono usate per aiutare a coordinare gli oggetti del dominio come parte di un caso d'uso. In quanto tale, questo tipo di oggetto generalmente rientra nell'ambito del proprio livello applicativo (dove tale coordinamento appartiene). Non posso davvero offrire una spiegazione più puntuale senza una descrizione più specifica di come stai usando il tuo Managers .

Per quanto riguarda il tuo livello di interfaccia utente, finché non esegui la logica di business con le tue "entità infornate" (anche se non sono entità se non sono completamente idratate), puoi recuperare i dati come meglio credi. Non è necessario un Repository per mediare il flusso / mappatura dei dati dal tuo negozio nel tuo dominio, perché non è necessario utilizzare oggetti di dominio per il lato di lettura della tua applicazione. Restituire set di dati semplici e grezzi è perfettamente accettabile. Se ti interessa la sicurezza del tipo, potrebbe essere nel tuo interesse creare DTO, ma spesso, come nel caso in cui sono richieste numerose letture ad hoc, questo è solo un lavoro in più per un piccolo beneficio.

Il più bizzarro per quanto riguarda i DTO verrà utilizzato come parte dell'infrastruttura dei comandi (livello applicazione) per garantire la sicurezza del tipo e la convalida semplice per i dati destinati a un gestore comandi.

    
risposta data 17.10.2018 - 23:03
fonte

Leggi altre domande sui tag