Mapping vs. livello di servizio, o la posizione logica di business

Question

ho ottenuto un prodotto e una collezione di contribuenti. I contribuenti possono pagare per il prodotto in tre modi diversi, ma sia manualmente impostare la percentuale, in base al reddito contribuenti o per il valore dei contribuenti rispettivi holdings.How il prodotto è pagato è determinato da un enum sul prodotto.

Nel mio strato di persistenza ho ottenuto tre classi, prodotto, Payer, e ProductManuallyPaid che è una relazione molti-a-molti di classe tra prodotto e Payer se il prodotto viene pagato da manualmente, specificando la percentuale ogni Payer dovrà pagare.

Come devo mappare questo alla vista? Mi piacerebbe avere una nuova relazione molti-a-molti di classe (che consisterebbe di un riferimento al pagatore, un riferimento al prodotto e l'importo esatto che contribuente dovrebbe pagare)?

Credo che il calcolo deve essere fatto in livello di servizio, ma dovrebbe tornare il livello di servizio di una versione ViewModel / DTO del Prodotto / Payer con un nuovo molti-a-molti di classe attaccato, o questo dovrebbe essere gestito in seguito? se deve essere gestita in seguito, qualora l'entità contenere un elenco di che nuova classe molti-a-molti, ma essere ignorato nel strato di persistenza?

Answer 1

DDD potrebbe suggerire che si dovrebbe adottare una linea di pensiero che si concentra in primo luogo sulla progettazione del modello di oggetti piuttosto che il modello ER / dati. Vedo che hai pensato a come il modello di dati dovrebbe apparire (con i molti-a-molti tavolo, ecc), ma forse si dovrebbe prendere in considerazione come il modello a oggetti potrebbe apparire prima. Poi, come quel modello oggetto riflette il dominio (logica di business, il comportamento delle imprese), pensare a come si potrebbe mappare quel modello oggetto nel database.

Per esempio, si potrebbe avere più senso per restituire un prodotto che ha una collezione di pagamenti. E ogni pagamento ha un collegamento per l'entità Payer. A seconda del progetto che Payer collegamento può avere copie della informazioni Payer si vuole accedere o forse che puntano sa come caricare l'entità pieno Payer le informazioni necessarie / valori. Inoltre, ogni istanza Payer potrebbe avere una collezione di pagamenti (stesso tipo di classe di cui sopra, anche?), Che avere un collegamento al prodotto.

Questo design fa un uso migliore delle principi OO e descrive il dominio migliore di modi in cui un database potrebbe relazionale. Inoltre, questi oggetti possono essere più facile da gestire nei servizi e strati di interfaccia utente, come la loro struttura oggetto nativo fornisce già logicamente con le cose che servono. vale a dire. un prodotto ha i pagamenti, che hanno il Payer, etc ..

Sono ragionevolmente nuovo a DDD a pensare. E prima che il termine DDD si spaventa, date un'occhiata a questo riepilogo di Evan libro . E 'una luce di lettura e da scaricare gratuitamente. Essa può solo darvi le gemme che state cercando.