Come gestire gli oggetti figlio che richiedono l'interazione DB per la loro logica aziendale

Question

Come gestire gli oggetti figlio che richiedono l'interazione DB per la loro logica aziendale

#1 da (4 voti)
#2 da (3 voti)

1

Ho iniziato a leggere Domain Driven Design .

Ho una situazione in cui una radice aggregata ha un oggetto figlio che ha bisogno dell'interazione DB per poter eseguire la sua logica di business perché una delle costanti utilizzate viene salvata nel DB.

Esempio:

L'utente crea un Customer
L'utente crea un Review su quel Customer
Review potrebbe essere approvata se l'età di Customer è inferiore a cutoffAge
La costante cutoffAge utilizzata nella logica aziendale Review viene salvata nel DB

class Customer {
  constructor(name, age) {
    this.name = name;
    this.age = age;
    this.review = null;
  }

  createReview() {
    this.review = new Review(this.age);
  }
}


class Review {
  constructor(age) {
    // Where 'approvalAgeCutoff' value should really come from the DB
    this.approvalAgeCutoff = 10;
    this.needsApproval = false;

    if (age < this.approvalAgeCutoff) {
      this.needsApproval = true;
    }
  }
}


// Usage

const customer = new Customer('John Doe', 15); 
customer.createReview();

Qual è un modo consigliato di gestirlo senza aggiungere codice di interazione DB nell'oggetto child Review ?

domain-driven-design design-patterns

posta Nik Kyriakides 17.07.2017 - 13:13

fonte

2 risposte

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

Uso intelligente del puntatore nella libreria della GUI Il modo migliore per costruire i nostri soggetti di prova nei test unitari?

score 4 · Answer 1

Trasmetteremo tutte le informazioni richieste come parametri del metodo per mantenere il Aggregate il più pulito possibile.

class Customer {
  constructor(name, age) {
    this.name = name;
    this.age = age;
    this.review = null;
  }

  createReview(approvalAgeCutoff) {
    this.review = new Review(this.age, approvalAgeCutoff);
  }
}


class Review {
  constructor(age, approvalAgeCutoff) {
    this.needsApproval = false;

    if (age < approvalAgeCutoff) {
      this.needsApproval = true;
    }
  }
}


// Usage, in an Application service

const approvalAgeCutoff = someDb.loadApprovalAgeCutoff();
const customer = new Customer('John Doe', 15); 
customer.createReview(approvalAgeCutoff);

Quindi, quando lo si utilizza, il codice client (il più probabile Application service ) caricherà quel valore dal DB e lo passerà a customer.createReview .

In questo modo mantieni l'Aggregate pulito e testabile senza usare una simulazione.

score 3 · Answer 2

What's a recommended way of handling this without adding DB interaction code in the Review child object?

Mi sembra un ReviewPolicy , o qualcosa del genere, con uno stato che vive al di fuori dell'aggregazione del cliente.

Pertanto, il solito modo di interrogare la politica all'interno di un comando che aggiorna l'utente sarebbe di utilizzare un servizio di dominio . Più comunemente, si passa il servizio di dominio all'aggregato come argomento nel comando; e le entità all'interno dell'aggregazione invocheranno la query quando ne avranno bisogno.