DDD - Quale potrebbe essere la soluzione migliore per AggregateRoot ed Entity for Transaction Domain

Question

DDD - Quale potrebbe essere la soluzione migliore per AggregateRoot ed Entity for Transaction Domain

#1 da (1 voti)

2

Presenterò questa domanda dicendo che sono relativamente nuovo alla DDD, quindi potrei fare alcuni errori fondamentali qui!

Sto lavorando a un progetto che coinvolge i concetti di Transazioni (in senso finanziario come Transazione con carta di credito, o Monotaglio / MultiploTransaction.). Una transazione può essere su una singola carta o più carte. L'importo della transazione può differire per ogni carta. Anche il Titolare della carta o il CardCustomer possono essere uguali o diversi.

Una transazione esegue un'esecuzione specifica della logica di business basata su TransactionTypes (come Activate, Redeem ....).

Una transazione eseguirà le seguenti operazioni - Convalida prima transazione su carta - Saldo dell'aggiornamento - Stato della scheda di aggiornamento - Aggiorna le informazioni del cliente - Transazione registro

Ora sono confuso per decidere quale potrebbe essere il mio aggregateroot qui.

Approccio 1

Usa transazione un'entità che detiene cardid, importo, customerid, tipo di transazione, transactionlogid come ValueObject e Card, CardAmountSummary, CardCustomer e TransactionLog come entità Crea Seperate AggreateRoot per SinglegiftCardTransaction, MultipleGiftCardTransaction, BookletTransaction, WalletTransaction ciascuno fungerà da wrapper per Transaction / s. Il limite di transazione può essere diverso in base alla massa o alla singola transazione.

Approccio 2

Utilizza Transaction come AggregateRoot contenente un elenco di Schede, Ogni Carta avrà CustomerId, Amount, CardAmountSummaryId, transactionlogid, transactiontypeid come oggetto Value.

Quale sarebbe la soluzione migliore per AggreateRoot ed Entità qui ???

domain-driven-design api-design design-patterns

posta Dinesh Patel 05.05.2018 - 09:07

fonte

1 risposta

Leggi altre domande sui tag domain-driven-design api-design design-patterns

Un'app può avere più "sottodomini" in DDD? microservizi metodi granularità

score 1 · Answer 1

Concettualmente, il problema che stai descrivendo è trovare un equilibrio tra la scelta degli oggetti che dovrebbero "possedere" i dati e quali oggetti dovrebbero "usare" quei dati. Mentre DDD (e OOP in generale) è un paradigma definito portando insieme dati e comportamenti, lo specifico tipo di comportamento che stai descrivendo semplicemente non può essere contenuto nello stesso oggetto del proprio che "possiede" il dati. Tenendo presente quanto sopra, la risposta alla tua domanda è ... nessuna delle due. Il miglior coordinamento tra le regole aziendali tra le entità è un servizio di dominio.

Considera l'esempio di prelevare denaro ( withdraw ) dal tuo BankAccount utilizzando un ATM . Il problema qui è che ci sono due transazioni che devono essere completate affinché il denaro venga distribuito, ciascuna con le loro proprie regole aziendali che devono essere applicate. Il metodo ATM.dispense è soggetto alla regola che l'ATM deve (fisicamente) disporre di una valuta sufficiente per erogare l'importo desiderato. E il tuo metodo BankAccount.debit richiede che tu disponga dei fondi disponibili nel tuo account. L'unico modo per imporre a livello transazionale che entrambe le regole siano applicate senza creare una dipendenza diretta tra le entità ATM e BankAccount è creare un oggetto ATMService che possa coordinare / mediare il processo di business tra le due entità che effettivamente "possiede " i dati. Il corpo del metodo withdraw potrebbe essere simile a:

// each of these could throw an exception 
atm.dispense( amount );
account.debit( amount );

È importante sottolineare che il metodo ATM.withdraw viene eseguito come parte di una singola transazione. Quindi, se c'è un errore in qualsiasi parte del processo, nulla è impegnato (tutto o niente). Transazione id e simili potrebbero essere aggiunti e utilizzati per la correlazione degli eventi, se necessario.

L'esempio sopra è simile alla tua prima opzione, ma differisce dal fatto che ATMService non "possiede" alcun dato (non è, di per sé, un aggregato). I dati e le transazioni intermedie sono tutti di proprietà e eseguiti dalle entità appropriate.

Per processi a esecuzione prolungata o asincrona, è possibile introdurre un gestore di processi per aiutare a mediare anche un flusso di lavoro.