Domain Driven Design - Recupera le informazioni relative a un'entità dal data base dopo che l'entità è stata creata

Question

Domain Driven Design - Recupera le informazioni relative a un'entità dal data base dopo che l'entità è stata creata

#1 da (3 voti)

3

Sono nuovo di DDD e sto lottando per trovare il modo corretto di risolvere un semplice problema.

Diciamo che sto lavorando a un progetto in cui sto elaborando carte di credito utilizzando un'API di terze parti che ha l'abilità di colpire un terminale di carta di credito o utilizzare le carte di credito salvate per elaborare un pagamento. Ho un'entità payment , un'entità request e un'entità token . payment ha attributi come payment_date , amount , ecc. nonché request_id . Un token può essere usato per bypassare il terminale della carta di credito. Si riferisce a una carta di credito utilizzata in precedenza, la quale viene archiviata con la società di elaborazione delle carte di credito.

Durante l'elaborazione dei rimborsi, devo conoscere l'ID del terminale della carta di credito che è stato utilizzato quando è stato effettuato il pagamento che è stato rimborsato. Questo è memorizzato nella tabella delle richieste nel database a meno che non sia stato utilizzato un token e il terminale della carta di credito non fosse necessario. L'entità token ha un attributo source_request_id che punta alla richiesta che lo ha creato. Può ottenere l'ID del terminale della carta di credito da quel record.

Le tabelle del database corrispondenti assomigliano a qualcosa.

tblPayment.id
tblPayment.amount
tblPayment.payment_date
tblPayment.request_id

tblRequest.id
tblRequest.terminal_id
tblRequest.token_id

tblToken.id
tblToken.source_request_id

Non sembra logico prendere il colpo di prestazioni per interrogare sempre il database per l'id del terminale, quando si crea l'entità payment , specialmente se è stato usato un token.

Potrei aggiungere un metodo getTerminalId all'entità payment che estrarrà request e token entità dai loro repository e userà quelli per trovare l'id del terminale. Da quello che ho capito, però, infrange le regole della DDD.

Usando DDD, come dovrei ottenere l'id del terminale per payment ?

domain-driven-design

posta bconrad 25.10.2017 - 23:00

fonte

1 risposta

Leggi altre domande sui tag domain-driven-design

Miglior design per le classi che disegnano oggetti ma non ereditano da JPanel Gestione degli errori ed eccezioni in un'architettura a strati (o cipolla) [chiusa]

score 3 · Answer 1

I could add a getTerminalId method to the payment entity that would pull request and token entities from their repositories and use those to find the terminal id. From what I understand, that breaks the rules of DDD though.

Esattamente quale regola del DDD pensi di violare qui?

L'unica regola che conosco viola questo è l'incapsulamento (che precede il DDD). I getter non forniscono l'incapsulamento (nonostante le segnalazioni in senso contrario). Tutto ciò che fanno è permetterti di impostare punti di rottura chiacchierando quando qualcuno ottiene. Permettono a chiunque di ottenere le informazioni come se il campo fosse pubblico.

L'alternativa è talvolta chiamata Tell, non chiedere . Seguendo questa regola smetterei di chiedere Payment per un ID terminale con getTerminalId() e indica a Pagamento che stai elaborando un rimborso con payment.refund() . Passeresti il pagamento il minimo necessario per fare il resto di questo lavoro e ti fideresti di fare il resto. Esattamente come ciò dipenderà dall'implementazione del pagamento, ma non è necessario o desidera saperlo. È un altro problema.

Cosa succede se le informazioni che ti servono sono sparse? Invia il comando attraverso ovunque che abbia le informazioni necessarie per raccoglierlo mentre vai. Quando hai abbastanza da fare qualcosa, fallo e fallo. Non è necessario che il chiamante gestisca tutto ciò. Questo funziona bene quando si rendono esplicite le dipendenze in modo da non dover indovinare quando qualcosa è in buono stato e pronto a funzionare.

Sto dicendo che tutti i getter sono malvagi e sbagliati? No. Ma so che il problema che causano è inizialmente sottile. È facile conviverci e iniziare a prendere ciò che ti serve non appena lo trovi. Ma un giorno vorrai cambiare le cose e scoprire che non puoi perché sembra che tutto sappia su cosa vuoi cambiare. È allettante prendere la strada facile. Non è facile tornare da esso.