DDD Best practice

1

Sto sviluppando alcuni progetti web di test per conto mio per imparare DDD e buona pratica architettonica. Quindi l'applicazione, in pratica, è un semplice gestore di foto.

Sto sviluppando un'architettura a 3 livelli e per ora ho:

  • DAL:
    • Primo database EF
    • UserRepository
    • PhotoRespoitory
    • UnitOfWork
  • BLL

    • UserService: registrazione utente, autenticazione, registrazione
    • PhotoService: recupero, caricamento e aggiornamento di foto
    • Modelli DTO: utente, foto, album
    • Automapper: mappatura DAO dal modello EF al modello DTO
  • Client MVC Asp.Net

Ecco alcuni esempi di modelli DTO:

public abstract class ModelBase
{
    public virtual long Id { get; protected set; }
}

public class User : ModelBase
{
    public string Name { get; set; }
    public string Email { get; set; }
    public UserRole UserRole { get; set; }
    public DateTime RegistrationDate { get; set; }

    public override string ToString()
    {
        return $"{Name} {Email} {UserRole} {RegistrationDate}";
    }
}


public class Photo : ModelBase
{
    public string Name { get; set; }
    public DateTime DateTaken { get; set; }
    public string Place { get; set; }
    public string CameraModel { get; set; }
    public string FocalLength { get; set; }
    public string Diaphragm { get; set; }
    public string ShutterSpeed { get; set; }
    public string ISO { get; set; }
    public bool? FlashMode { get; set; }
    public long OwnerId { get; set; }
    public string OwnerName { get; set; }
    public long AlbumId { get; set; }
    public string AlbumName { get; set; }
}

Quindi le mie domande sono:

  1. Ha senso creare modelli di dominio con qualche logica, dato che la logica di manipolazione del modello è stata delegata al servizio?

  2. BLL è il posto giusto per i modelli DTO?

  3. Devo creare un ApplicationService aggiuntivo che conterrà PhotoService e PhotoService e trova l'utente che carica l'immagine e quindi passa il UserDto con PhotoDto a PhotoService ?

posta Alexander Smith 31.07.2018 - 16:28
fonte

2 risposte

1

1) Does it make sense to create domain models with some logic, as model manipulation logic was delegated to service?

Non hai davvero specificato cosa intendi per "modello di dominio". Questa definizione è importante in quanto alcuni sviluppatori considerano le loro entità di database come il loro modello di dominio, mentre altri mantengono un progetto di dominio separato che contiene le interfacce e le classi di base che sono ereditate / implementate dai livelli DAL / BLL effettivi.

  • Se fai riferimento alle classi DTO, puoi aggiungerle alla logica.
  • Se si fa riferimento alle entità del database, non è necessario aggiungervi la logica. Nella migliore delle ipotesi, puoi fare un compromesso e consentire ad es. una semplice conversione di proprietà ( public string FullName => FirstName + LastName; ) ma nessuna logica effettiva.
  • Se si fa riferimento alle interfacce / classi base per gli oggetti DAL / BLL, può essere utile aggiungere una logica di base, anche se è necessario assicurarsi che sia indipendente dalla dipendenza. Più spesso, la logica che intendi aggiungere non sarà indipendente dalla dipendenza.

Questa domanda è un po 'troppo aperta per una risposta diretta. Alcuni sviluppatori mantengono un modello anemico in cui classi di dati e classi logiche sono strettamente separate. Altri sviluppatori sostengono che questo è contrario ai principi OOP.

Non sto prendendo una decisione qui pro / anti-anemico. O l'approccio ha il suo beneficio. E, se siamo onesti, la maggior parte degli sviluppatori dovrebbe seguire comunque l'approccio preferito dal capo tecnico / senior.

2) Is BLL the right place for DTO models?

Tecnicamente, il livello ogni richiede i propri DTO. Ma penso che molte persone siano d'accordo sul fatto che lo sforzo per farlo non superi i benefici.

Se hai solo un livello DTO, il livello aziendale è il posto dove metterli. In sostanza, la regola generale è che le entità del database non fuoriescono dal tuo BLL.

3) Do I need to create an additional ApplicationService, that will contain PhotoService and PhotoService and finds user that uploads picture and then pass the UserDto with PhotoDto to PhotoService?

Non lo chiamerei ApplicationService . Ma può essere significativo avere un servizio chiamato dopo una funzione piuttosto che un'entità .

Ad esempio, UserService gestisce l'utente CRUD, RoleService gestisce il ruolo CRUD, ma AuthorizationService gestisce la combinazione dei due: accessi, risoluzione delle autorizzazioni, ... E riutilizza la logica da UserService / RoleService dove rilevante.

Non avrebbe molto senso inserire la logica login / permesso in o il UserService o RoleService poiché dipende in gran parte da entrambi. Gli sviluppatori non sono d'accordo con la sua posizione o, ancora peggio, iniziano a mescolarli.

Penso che la risposta diretta più breve alla tua domanda sia che i servizi non devono puntare a una particolare entità di database.

    
risposta data 01.08.2018 - 17:27
fonte
-1

Poiché hai codificato la tua domanda con object-oriented :

  1. Sì, aggiungere la logica agli oggetti "modello" ha senso. In realtà è l'intero punto di orientamento all'oggetto. Ogni pezzo di logica che deve lavorare direttamente con i dati ha per essere nell'oggetto in effetti. In realtà è una pratica peggiore nell'orientamento agli oggetti per esporre i dati (si applicano alcune eccezioni).

  2. "DTO" in realtà non dovrebbe esistere, in primo luogo, non importa dove siano.

  3. Gli oggetti "Service" e "DTO" non dovrebbero esistere. Avere "servizio" "oggetti" implica che alcune logiche di business non abbiano trovato il loro posto in un vero oggetto di business da qualche parte. Può anche implicare un'astrazione mancante. Inoltre, gli oggetti "Service" e "DTO" sono parte non del dominio. Sono tecnici e non possono essere discussi con gli uomini d'affari.

L'architettura a cui stai pensando è il "tradizionale", strongmente accoppiato, procedurale, tecnicamente stratificato "design d'impresa". Non è considerato sbagliato utilizzarlo (puoi usarlo se vuoi), ma non ha quasi nulla a che fare con l'orientamento agli oggetti.

    
risposta data 01.08.2018 - 12:16
fonte

Leggi altre domande sui tag