Richiesta di modellazione / risposta nella progettazione orientata al dominio

Question

Richiesta di modellazione / risposta nella progettazione orientata al dominio

#1 da (5 voti)

2

Dire che ho una classe di utente e che l'utente ha un ID & Nome, nella modellazione di risposta richiesta, vorrei fare una richiesta con Nome su di esso e una risposta con Id e Nome, quindi il mio modello di dominio sarebbe

public User
{
    public int Id { get; set; }
    public string Name {get; set; }
}

In SOA (web api) questo è sempre un po 'dispendioso come stai facendo una richiesta con un ID sempre NULL. Ora passiamo a qualcosa di complesso che non entrerò nei dettagli e dirò che l'utente ha ora 20 proprietà, di cui 5 oggetti complessi, quindi la tua richiesta http aumenterà. Per renderlo più divertente, diciamo che alcune di queste proprietà non possono essere esposte all'interfaccia utente (ad esempio hash e amp; salt).

Qual è l'approccio raccomandato per la gestione di questo scenario comune nell'architettura SOA utilizzando la progettazione basata su domini?

Modifica: la mia domanda riguarda più richiesta / risposta che conversione di dominio in dto, penso che il takeaway sia request = dto & response = dto.

domain-driven-design domain-model soa modeling

posta RandomUs1r 29.08.2018 - 23:54

fonte

1 risposta

Leggi altre domande sui tag domain-driven-design domain-model soa modeling

Pessima idea mostrare le informazioni del server di posta nel progetto github pubblico? Passare un oggetto di contesto al costruttore o al metodo

score 5 · Accepted Answer

Domain Driven Design non fornisce una risposta per questo. DDD è più focalizzato sulla logica di business. Il tuo problema è come rappresentare i dati come una stringa di caratteri inviati ae da un client attraverso una rete.

Ciò di cui hai bisogno è un DTO (Data Transfer Object). Ogni volta che è necessario trasferire dati tra processi, in cui la chiamata a un altro processo è la parte costosa dell'operazione (come di solito avviene con le richieste HTTP), allora è necessaria una classe o un gruppo di classi specializzate nei dati che vengono trasmessi - non comportamento: dati e solo dati. Le DTO tendono ad avere getter e setter pubblici. Possono essere composti da altri DTO, ma non dovrebbero contenere alcun metodo.

La struttura di questi DTO può essere utilizzata per serializzarli in una stringa per la trasmissione su una rete, come in Architettura orientata ai servizi. Mentre Martin Fowler consiglia di associare la serializzazione e la deserializzazione di DTO insieme nello stesso oggetto (il che significa aggiungere metodi a un DTO). può anche essere realizzato con librerie di terze parti. Ogni stack tecnologico ha librerie per la conversione da e verso JSON e XML, che sono formati di dati piuttosto standard. Queste librerie spesso utilizzano la riflessione della classe per dedurre la struttura dei dati dai membri dell'oggetto e digitare le informazioni.