Mapping di oggetti business a oggetti dati

Question

Mapping di oggetti business a oggetti dati

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

0

Vedi il codice qui sotto, che è un metodo di fabbrica in un modello di dominio ricco (livello dominio). Ci sono due cose che non mi piacciono:

public class SalesPersonOfferFactory (Applicant applicant)
    {
        if (applicant.Age > 30 && applicant.Employed = true)
        {
            return new PersonOffer (52, applicant.id)
        }
        else if (applicant.Age < 30 && applicant.Employed = true)
        {
            return new PersonOffer (164, applicant.id)
        }
        else if (applicant.Age > 30 && applicant.Employed = false)
        {
            return new PersonOffer (196, applicant.id)
        }
        else if (applicant.Age < 30 && applicant.Employed = false)
        {
            return new PersonOffer (242, applicant.id)
        }
    }

PersonOffer accetta un OfferID e ApplicantID (rilevante per il database).

La preoccupazione che ho è che il livello del dominio deve conoscere i numeri ID dal database, cioè deve sapere che OfferID 52 è rilevante se il richiedente ha più di 30 anni ed è impiegato e deve sapere che l'offerta 164 è rilevante se il richiedente ha meno di 30 anni ed è occupato ecc.

Capisco che sto pensando a questo in modo errato. Come posso creare oggetti business nel livello dominio che richiedono la mappatura al livello dati? C'è uno schema per questo?

Sarebbe normale utilizzare le chiavi naturali che descrivono l'offerta, ad es. 52 è: PremierCard quindi direbbe:

if (applicant.Age > 30 && applicant.Employed = true)
        {
            return new PersonOffer ('PremierCard', applicant.id)
        }

Ci deve essere un modo migliore per farlo.

c# domain-driven-design

posta w0051977 11.07.2017 - 11:23

fonte

2 risposte

Leggi altre domande sui tag c# domain-driven-design

Esecuzione e mantenimento di un mega progetto "live" Errori disambiguanti per lo stesso codice di stato HTTP

score 2 · Answer 1

Con riferimento a questa e alla tua domanda precedente, Crea un oggetto entità nel livello dominio quando l'ID è sconosciuto , sembra che stia memorizzando i tipi di carte nel database e regole hard-coding attorno a quelle carte nel codice.

Ciò significa che se si desidera aggiungere una nuova scheda, è necessario che entrambi riapplichino l'applicazione e aggiornano il database. Ciò rende sia il test che il rilascio più difficili di quanto sia necessario.

Suggerirei quindi di scegliere tra l'archiviazione delle regole aziendali nel database o il codice rigido dei tipi di carte nell'applicazione. In questo modo, è necessario solo aggiornare il database o ri-rilasciare l'applicazione quando sono necessari nuovi tipi di schede.

Se questo non è "il modo DDD", allora non farlo nel modo TDD. Rendere la vita più difficile per te stesso seguendo ciecamente il modo idealizzato di fare le cose di qualcun altro non è mai una buona idea.

score 0 · Answer 2

Would it be normal to use natural keys that describe the offer e.g. 52 is: PremierCard

Dipende davvero.

Nel linguaggio ubiquitario del dominio, il termine "52" è significativo e usato / compreso dalle persone che fanno offerte alle persone di vendita? Se "sì", allora va tutto bene. Se "no", probabilmente dovresti trovare un modo migliore di rappresentare queste cose, ad esempio chiamarlo "PremierCard" che è molto vicino - se non esatto - in uso a come sono nel loro uso quotidiano.

Inoltre, se si trattasse di un "modello di dominio ricco", il codice dovrebbe probabilmente leggere qualcosa di simile

if (applicant.IsOver30AndEmployed())
{
    return new PremierCardOffer(applicant);
}
if (applicant.IsAYoungAdultAndEmployed())
{
    return new NotSoPremierCardOffer(applicant);
}
//and so on

dove PremierCardOffer e simili possiedono la consapevolezza che si tratta di Offer Type 52, o 164 o qualsiasi altra cosa:

class PremierCard: SalesPersonOffer
{ 
    public int OfferTypeId => 52;

    public PremierCard(Applicant applicant)
    {
     //whatever you need to do
    }
}

e così via. In questo momento, suppongo che tu abbia un dominio anemico con la ricca funzionalità sparsa tra servizi, fabbriche e gestori. Non necessariamente un cattivo design, ma estremamente limitante quando si tenta di modellare un dominio.