Quale layer per tipo personalizzato (DDD)

3

Se ho un tipo personalizzato (o forse un enum) come per es. a Range :

Public Class Range

    Sub New(minimum As Single, maximum As Single)
        Me.Minimum = minimum
        Me.Maximum = maximum
    End Sub

    Public Property Minimum As Single 
    Public Property Maximum As Single 
    Public ReadOnly Property Delta As Single 
        Get
            Return Maximum - Minimum
        End Get
    End Property
End Class
'-----------
'Some methods...

Questo tipo dovrebbe essere usato nel modello di dominio (implementando DDD), nella logica di business quando si fa roba e anche nel livello dati, dove verrà memorizzato come un tipo complesso.

Quindi:

  • dovrei definire tali classi in un progetto App.Common e fare riferimento a questo assembly ovunque ( la mia scelta per ora, ma non so se avere riferimenti nel progetto del modello di dominio è un anti-pattern? )
  • dovrei definirlo nel mio modello di dominio e fare riferimento al mio modello di dominio ovunque sia necessario. ( forse meglio? dato che il modello di dominio è fondamentale in DDD, ma il tipo non è un dominio o un oggetto valore ... )
  • dovrei creare classi diverse per ogni livello ( che non hanno senso per me, dal momento che voglio gestirlo come un altro tipo e non come Object )?

Modifica Nel mio caso, utilizzo range come MeasuringRange per i dispositivi di misura. Per es. un termometro che può misurare da 0 ° F a 250 ° F:

public class Thermometer
{
    public Thermometer(Range measureRange)
    {
        this.MeasureRange=measureRange;
    }

    public Range MeasureRange {get;set;}
}

Al momento viene anche utilizzato nel DataLayer (utilizzando prima il codice EF) per memorizzare l'intervallo di dispositivi come un tipo complesso (EF crea campi MeasureRange_Max e MeasureRange_Min .

Viene anche utilizzato nei servizi nella BLL quando si eseguono alcune misurazioni con i dispositivi.

    
posta R. Gomez 02.01.2018 - 12:17
fonte

2 risposte

3

Non credo che ci sia una risposta autorevole a questo.

La mia ipotesi è che dovremmo trattare Range come una sorta di convenienza agnostica del dominio per l'implementazione. È in qualche modo analogo a System.Collections in questo senso.

Inoltre, sembra che il componente dell'applicazione potrebbe volerlo utilizzare anche se il componente del dominio non lo fa (e viceversa), il che implica che appartenga a un componente separato che entrambi potrebbero condividere.

should I define such classes in a Project App.Common and reference this assembly everywhere

Questo è l'approccio che ha più senso per me.

should I define it in my domain model and reference my domain model everywhere where it is needed.

Probabilmente no - il modello di dominio ha un sacco di peso da inserire in una libreria. A meno che Range e Delta facciano parte della lingua del tuo dominio, la dipendenza è in realtà un dettaglio di implementazione che non dovrebbe essere ovvio per i client del modello di dominio.

should I create different classes for each layer (which don't make sense to me, since I want to handle it like another type and not as Object)?

Non vedo molto vantaggio lì, allo stesso modo non vedo un vantaggio nella duplicazione di una raccolta su più componenti.

    
risposta data 02.01.2018 - 13:51
fonte
2

Una grande idea in DDD è che il livello Dominio non dipende da nessun altro livello (ad esempio presentazione, infrastruttura, applicazione ecc.). Questa regola esiste quindi questo strato contiene pure , facilmente testabile, effetti collaterali logica aziendale gratuita.

Tuttavia, al fine di implementare questa logica aziendale, dobbiamo utilizzare e riutilizzare alcune classi di base come elenchi, indirizzi e-mail, intervalli (come i tuoi), intervalli di tempo, ecc. Queste classi, sebbene non ci siano dal linguaggio Ubiquitous, sono importanti costrutti di supporto. Mantengono il nostro codice DRY .

In base al DIP , il livello Dominio dovrebbe possedere questi costrutti. Ciò implica che dovrebbe risiedere nel livello Dominio . Puoi inserirli in una directory annidata, ad esempio Domain/Base , per separarli da Entities , Aggregates e Value objects ma per tenerli chiusi.

    
risposta data 02.01.2018 - 14:09
fonte